cancel
Showing results for 
Search instead for 
Did you mean: 

another CSRF issue with Alfresco share and docker

jjengel11
Champ on-the-rise
Champ on-the-rise

I am having problems getting the alfresco community edition 7.0 using provided docker-compose.yml to work when enabling SSL in the proxy.

I've tried to use this as a reference

https://hub.alfresco.com/t5/alfresco-content-services-blog/introducing-the-csrfpolicy-in-alfresco-sh...


by setting these variables in the share container in docker-compose.yml.

CSRF_FILTER_ORIGIN
CSRF_FILTER_REFERER

and by trying to disable the filter but nothing seems to work

I modified the dockerfile to look like this (for share and proxy)

share:
    image: alfresco/alfresco-share:7.0.0
    mem_limit: 1g
    environment:
        REPO_HOST: "alfresco"
        REPO_PORT: "8080"
        CSRF_FILTER_ORIGIN: https://d-alfresco-tester.my.domain.com
        CSRF_FILTER_REFERER: https://d-alfresco-tester.my.domain.com/.*
        JAVA_OPTS: "
            -XX:MinRAMPercentage=50
            -XX:MaxRAMPercentage=80
            -Dalfresco.host=localhost
            -Dalfresco.port=8080
            -Dalfresco.context=alfresco
            -Dalfresco.protocol=http
            "

proxy:
    image: alfresco/alfresco-acs-nginx:3.2.0
    mem_limit: 128m
    environment:
        DISABLE_PROMETHEUS: "true"
        DISABLE_SYNCSERVICE: "true"
        DISABLE_ADW: "true"
        USE_SSL: "true"
        DOMAIN: "*.my.domain.com"
    depends_on:
        - alfresco
    ports:
        - 443:443
    links:
        - alfresco
        - share
    volumes:
        - /etc/pki/public/wildcard.crt:/etc/nginx/ssl/cert.crt
        - /etc/pki/private/wildcard.key:/etc/nginx/ssl/cert.key

With this configuration, when I access


https://d-alfresco-tester.my.domain.com/alfresco/

it works just fine, however, after logging into the share


https://d-alfresco-tester.my.domain.com/share/

I get this

400 bad request
The plain HTTP request was sent to HTTPS port

I can see this in the proxy log


http://d-alfresco-tester.my.domain.com:443/share/page/

If I modify the origin to have a trailing '/'

CSRF_FILTER_ORIGIN: https://d-alfresco-tester.my.domain.com/

The alfresco link is fine again, however I get the csrf filter errors with the share link

I get the alfresco page that says

Something's wrong with this page...

and I see this in the share logs

Possible CSRF attack noted when asserting origin header 'https://d-alfresco-tester.my.domain.com'. Request: POST /share/page/dologin

If I click the *Back to My Dashboard* button, I get the

The plain HTTP request was sent to HTTPS port

I am not sure what I am missing based on some of these links where it seems setting the origin and referer was the solution


https://hub.alfresco.com/t5/alfresco-content-services-blog/introducing-the-csrfpolicy-in-alfresco-sh...
https://armedia.com/blog/a-tale-of-alfresco-share-with-csrf-and-bad-information/
http://www.giuseppeurso.eu/en/alfresco-tips-and-tricks-13-csrf-filter-error-on-share-login-with-apac...

If I disable the filter I get the following after logging into the share page

The plain HTTP request was sent to HTTPS port

I attempted to modify the nginx proxy to set origin and referer headers with no luck of the share working.

I don't think this should be needed but I tried to modify the alfresco-global.properties in the alfresco container with

# CSRF filter overrides
csrf.filter.enabled=true
csrf.filter.referer=^https?://d-alfresco-tester\.my\.domain\.com(/.*)?
csrf.filter.referer.always=false
csrf.filter.origin=^https?://d-alfresco-tester\.my\.domain\.com(/.*)?
csrf.filter.origin.always=false

and still no luck with the alfresco share Smiley Sad I do not understand what I am doing wrong based on some of the links I found.

Thanks for any help

3 REPLIES 3

afaust
Legendary Innovator
Legendary Innovator

It sounds to me like your proxy setup is not properly handling the forwarding of the protocol / scheme towards the Alfresco Share Tomcat backend, so that Tomcat uses the scheme of its connector to generate (back)links, because it is not aware of the fact that the nginx handles an HTTPS connection. Make sure your nginx forwards the protocol information (in addition to port + host, which I believe nginx does by default).

jjengel11
Champ on-the-rise
Champ on-the-rise

Thanks for the response to this.  I will look into your suggestions and let you know.

I found my issue.  My nginx config had this set



proxy_set_header Host $host:$server_port;

Which was causing the 

The plain HTTP request was sent to HTTPS port

I set to this just $host and all is working now