[v1.7] Your CSRF verification failed, reverse proxy not working?

[qcasey]

1.7.0 Breaking Change: PAPERLESS_URL

If you're behind a reverse proxy, the configuration variable PAPERLESS_URL needs to be set. See the Documentation about this variable to determine the correct value, typically it will just be your domain (i.e. https://paperless.xxxx.com).

Please remember to not add the trailing slash (https://paperless.xxxx.com/).

#674 explains why we needed to make this change.

Docker

Edit your docker-compose.env and add this variable.

PAPERLESS_URL=https://paperless.xxxx.com

Then force recreate your container (docker compose up -d --force-recreate).

Unraid

Add this variable similarly to the screenshot below.

• Name/Key: PAPERLESS_URL
• Value: https://paperless.xxxx.com

Bare Metal

Add/Edit this variable in your paperless.conf:

PAPERLESS_URL=https://paperless.xxxx.com

Then restart paperless-ngx.

[qcasey]

I think we should leave this up for several days after the 1.7.0 release.

[auanasgheps]

Thankfully was an easy fix, my legs started to shake when I saw the CSRF error.

I had a similar Django problem Django with TandoorRecipes TandoorRecipes/recipes#959 which took a lot of investigation to fix, but thankfully Paperless-ngx happily accepted the new variable.

Please add it to the .env / docs! I searched and is not yet there!

[qcasey]

Please add it to the .env / docs! I searched and is not yet there!

The variable is in the beta-branch of the docs, although we should add this note to the nginx config docs as well. I'll do that now.

It was also added to the install script and example .env for any new installs in ca0e867

[cl445]

Do any of you have a working configuration for Traefik as a reverse proxy? The documentation does only contain a configuration for Nginx.

[shamoon]

See jonaswinkler/paperless-ng#1148 (comment) , other than adding PAPERLESS_URL (and changing the image obv) that hasn't changed with the move to -ngx

[cl445]

@shamoon Thanks, but this is not the problem. I had a working installation with traefik for v1.6, but the CSRF-verification breaks it in v1.7 .
I was hoping that someone else has already done the necessary adjustments for traefik and is willing to share his configuration.

[StarkZarn]

@shamoon Thanks, but this is not the problem. I had a working installation with traefik for v1.6, but the CSRF-verification breaks it in v1.7 .
I was hoping that someone else has already done the necessary adjustments for traefik and is willing to share his configuration.

I'm running into the exact same issue. CSRF fail despite the new environment variable.

Nevermind. I made a stupid error. The environment variable does work properly with my Traefik setup. @cl445 not sure what you're running into here.

[shamoon]

I was hoping that someone else has already done the necessary adjustments for traefik and is willing to share his configuration.

That link does contain my working traefik config

[morremeyer]

Thanks for the good documentation!

As this has been noted as a breaking change, but the major version number has not been bumped, I’m curious as to what we regard as the public API that the versioning is based on?

If we see „the software can be used to archive and retrieve documents“ as the public API (which I think is what we should do and what this being noted as breaking changes suggests), this version bump should have been to 2.0.0, not to 1.7.0 as per semver specification.

Is there a specific reason for deciding against that?

I can also make this a separate issue if we want to discuss this at more length.

[qcasey]

Is there a specific reason for deciding against that?

Paperless' backend API, which serveral apps and scripts depend upon, is unaffected by this change. Personally that's what I have in mind when versioning, although we work as a team and our group semver strategy has not been explicitly defined. We can discuss in a new issue if that should be changed.

[axgdcode]

I use synology reverse proxy and I get the same error :
[2022-05-02 00:29:53,093] [WARNING] [django.security.csrf] Forbidden (Origin checking failed - https://xxxxx/ does not match any trusted origins.): /accounts/login/

I already added PAPERLESS_URL env variable and I didn't add the trailing slash.

[shamoon]

I already added PAPERLESS_URL env variable and I didn't add the trailing slash.

PAPERLESS_URL is pretty much just an alias for CSRF_TRUSTED_ORIGINS (And a couple others), if neither of those settings work then I would guess there is a reason that is not a “bug”, like either your setup is stripping the header, it’s set incorrectly etc. CSRF_TRUSTED_ORIGINS is a core Django setting so I imagine it is working various environments but likely some need tweaking. It’s hard to know how to diagnose these issues when it works for others and there’s not a clear cause, of course we can’t test every possible deployment setup. We would welcome any further detail.

[schlaggi]

In CSRF_TRUSTED_ORIGINS I'd be able to have multiple Domains with ['first.domain.com','second.domain.com'], but that seems to not be possible with PAPERLESS_URL. Has anybody else tried this?

[shamoon]

In CSRF_TRUSTED_ORIGINS I'd be able to have multiple Domains with ['first.domain.com','second.domain.com'], but that seems to not be possible with PAPERLESS_URL.

You are correct, thats why the documentation notes that PAPERLESS_CSRF_TRUSTED_ORIGINS, PAPERLESS_ALLOWED_HOSTS PAPERLESS_CORS_ALLOWED_HOSTS are all still available if you need more advanced settings

[Romanicus]

Setting the PAPERLESS_URL works for me, but instead of simply restart the docker-compose as it is told in this ticket (docker compose up -d) I had to start the containers again with recreation (docker compose up -d --force-recreate). This does the trick at my installation.

[cl445]

@Romanicus Thank you! That did also the trick for me!

[qcasey]

I had to start the containers again with recreation (docker compose up -d --force-recreate). This does the trick at my installation.

Thank you, I've edited that into the OP

[axgdcode]

I use synology reverse proxy and I get the same error : [2022-05-02 00:29:53,093] [WARNING] [django.security.csrf] Forbidden (Origin checking failed - https://xxxxx/ does not match any trusted origins.): /accounts/login/

I already added PAPERLESS_URL env variable and I didn't add the trailing slash.

I change the reverse proxy configuration and it works !

[10of12]

What did you changed on the Synology reverse proxy configuration?
I tired the settings from the Docs -> https://paperless-ngx.readthedocs.io/en/beta/setup.html#using-nginx-as-a-reverse-proxy
But it is not working. The PAPERLESS_URL variable is already set

The PAPERLESS_URL was wrong. Now everything is working.

[rdb81]

I have the CSFR issue and don‘t know how to fix it.
I have added PAPERLESS_URL: https://cloud.xxx-xxx.de. I‘m using the internal reverse proxy of my synology ds. So I‘m able to reach paperless with my domain but can‘t log in. When i try to log in the CSRF Page appears and my docker container log says: WARNING] [django.security.csrf] Forbidden (Origin checking failed - https://cloud.xxx-xxx.de:8770 does not match any trusted origins.): /accounts/login/

What did I wrong? I‘m also not able to change the enviroments with protainer. is this a bug? sorry, i‘m new to all of this. if you need any further information to help my, please give me i sign.

thnx in advance
rdb

[10of12]

Try changing the PAPERLESS_URL to https://cloud.xxx-xxx.de:8770
This is what worked for me. Also Synology with the internal reverse proxy

[stfnx]

I do have the same issue, but setting PAPERLESS_URL=https://paperless.sub.domain.tld didn't work for me.

I've installed paperless-ngx manually and setup a nginx reverse proxy according to the docs.

I come to the login page but after that I get Origin checking failed - null does not match any trusted origins..

# /opt/paperless/paperless.conf

PAPERLESS_URL=https://paperless.sub.domain.tld
#PAPERLESS_CSRF_TRUSTED_ORIGINS=
#PAPERLESS_ALLOWED_HOSTS=
#PAPERLESS_CORS_ALLOWED_HOSTS=

# nginx vhost conf

server {
    listen 443 ssl http2 default_server;
    server_name paperless.sub.domain.tld;

    # TLS Certificates
    ssl_certificate         /etc/nginx/certs/paperless.sub.domain.tld/fullchain.pem;
    ssl_certificate_key     /etc/nginx/certs/paperless.sub.domain.tld/key.pem;
    ssl_trusted_certificate /etc/nginx/certs/paperless.sub.domain.tld/ca.pem;

    include /etc/nginx/certs/tls.conf;
    include /etc/nginx/certs/security_headers.conf;

    #####################################################################

    location / {
        proxy_pass http://localhost:8000/;

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_redirect off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $server_name;
    }
}

Any help would be highly appreciated.

[simonkurka]

@stfnx I think this is more related to #817

I compared the response headers when removing a tag with the login page. The login page doesn't set the access-control-allow-origin header. I didn't figure out yet, why this leads to Origin: null, but at least Google Chrome behaves in this way. When the access-control-allow-origin is set in the response headers the Origin ist also set in the request.

@shamoon I feel like this better fits in #817, but it's closed. What is your suggestion? New issue? Reopen #817?

[simonkurka]

I removed add_header Referrer-Policy "no-referrer" always; which solved the issue, but I think the access-control-allow-origin header should still be set on the login page.

[diesl]

Then force recreate your container (docker compose up -d --force-recreate).

This has cost me 2 hours of searching why my settings did not work.
IMHO, this is missing in the documentation?

[egodigitus]

Was running paperless on proxmox within a LXC container.
Setting PAPERLESS_URL=https://paperless.sub.domain.tld within /opt/paperless/paperless.conf worked for me.
Important: Restart the LXC container!

Didn't had to change anything on my nginx reverse proxy

[onjour]

I use synology reverse proxy and I get the same error : [2022-05-02 00:29:53,093] [WARNING] [django.security.csrf] Forbidden (Origin checking failed - https://xxxxx/ does not match any trusted origins.): /accounts/login/
I already added PAPERLESS_URL env variable and I didn't add the trailing slash.

I change the reverse proxy configuration and it works !

Would you mind telling what did you change in the reverse proxy configuration exactly?

[flemmingss]

I have this problem also, I can't get it to work. (Using HAProxy on pfSense as reverse proxy)
I can access the login page, but after that I get Forbidden (403) CSRF verification failed. Request aborted

Log:

[2023-03-11 21:29:22,678] [WARNING] [django.security.csrf] Forbidden (Origin checking failed - https://paperless-ngx.mydomain.top does not match any trusted origins.): /accounts/login/

with: -e 'CSRF_TRUSTED_ORIGINS'='10.0.24.10,paperless-ngx.mydomain.top,https://paperless-ngx.mydomain.top'

[Robert-litts]

@flemmingss I ran into this issue yesterday (using HAProxy on OPNsense) when I went to go run Paperless-NGX in Portainer. This led me to this Github issue which I troubleshot for a few hours. Today, I completely tore down my setup and stood it back up by doing the following:

1. I am using the docker-compose.portainer.yml template.
2. I put this exact docker-compose file into a Portainer stack and added the following Env Variables:
   PAPERLESS_URL: https://paperless.mydomain.me
   PAPERLESS_CSRF_TRUSTED_ORIGINS: https://*.mydomain.me
   PAPERLESS_CORS_ALLOWED_HOSTS: https://paperless.mydomain.me
   PAPERLESS_TIME_ZONE: America/New_York
   PAPERLESS_SECRET_KEY:
3. Went into console of the Web Server to open the command line inside the container and ran 'python3 manage.py createsuperuser' to create a user.

Doing this, I was able to successfully log into https://paperless.mydomain.me without receiving the CSRF verification error!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.