nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

CSRF Filter with Chrome!

t16

Hi guys,

Really simple problem here I hope…

Ive configured the CSRF filter to work and allow requests from a reverse proxy, and all is well using the override code in share-custom-config…

<config evaluator="string-compare" condition="CSRFPolicy" replace="true">
      <properties>
<token>Alfresco-CSRFToken</token>
<referer>https://www.serverxx/* etc etc </referer>
<origin>https://www.serverxx/* etc etc *</origin>
</properties>
   </config>


All works wonderfully in IE, but with Chrome, the CSRF filter is triggered ALL the time.

Does anyone know why this is, and what I can do as a workaround?!

many thanks.

Find more posts tagged with

Comments

idwright

Have you made any progress with this?
(Also works in Firefox)

Thanks.

thamilanga

Has anyone been able to resolve this?

Thanks

vmayer

Hi folks,

we are having the exactly same problem here. We are using Alfresco Community 5.1 with Alfresco Share behind an nginx used as SSL offloader. The CSRF filter is triggered always when using Chrome (OSX, Linux, Windows) or Safari (OSX) or Chromium or Epiphany (both on Linux). The filter is not triggered (i.e. Share web access works) when using IE11 or Edge on Windows 10 respectively IE11 on Windows 7. There are also no problems with Firefox (OSX, Linux, Windows), so Firefox can be used as a workaround. Our working hypothesis is thus, that the problem is somehow tied to Webkit based browsers.

Can anybody confirm (or disprove) this hypothesis or can shed some more light on the issue?

Best regards, V. Mayer

vmayer

Hi folks,

I just wanted to share my solution, even though I haven't explored further why this makes a difference. Below you can find a snippet from my share-config-custom.xml:

      <properties>

         <!– There is normally no need to override this property –>
         <token>Alfresco-CSRFToken</token>

         <!–
            Override and set this property with a regexp that if you have placed Share behind a proxy that
            does not rewrite the Referer header.
         –>
         <referer>https://myserver.mysld.tld/share/.*</referer>

         <!–
            Override and set this property with a regexp that if you have placed Share behind a proxy that
            does not rewrite the Origin header.
         –>
         <origin>https://myserver.mysld.tld</origin>
      </properties>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

It didn't work as described before, if there still was a trailing slash (or anything more than that) in the origin element. Initially I had the identical content in the origin element as the one in the referer element. After deleting everything after the server name including the slash in the URL within the origin element resulting in the snippet above, all problems were gone.

Best regards, V. Mayer