Req and user empty when running behind NGINX reverse proxy

[TomDoFuture]

Bug Report

When using Nginx reverse proxy, req is empty, and thus req.user is undefined. This means access controls get scuffed. So you will never be allowed to do anything... Even logging out even if you are admin.

Strangely, with the way I have configured things the initial login works, but logging out doesn't.

Steps to Reproduce

1. Have Nginx and Payload running on separate docker containers in a docker network with docker-compose
2. Run a payload server, make sure you set your serverUrl to a plain url without a port. If you actually do choose a port then you won't even be able to see the admin panel post-login so the problem is even worse.
3. Nginx and reverse proxy to payload
4. You are able to login and view everything as admin, but doing ANYTHING, even logging out is a nono because the access control gets no req, and hence req.user is undefined.

##Important details

get requests seem to sort of work (In the chrome dev tools network tab, there are 2 requests made to each endpoint, one gets 403 and one gets 200)

Post requests somehow don't due to empty req.

Other Details

If you used a port in your serverUrl and reverse proxy to that, you won't even see the admin panel, and the same error occurs but worse, req will still be empty, but will even be empty for the initial /api/access fetch request when logging in.

Without a port, by just setting serverUrl to http://localhost , /api/access works normally, but everything you do post login is rekt.

More info gained from this discussion

Everything works on local

rateLimit.trustProxy = true doesn't fix it

[DanRibbens]

Have you set rateLimit.trustProxy: true in your config?

https://payloadcms.com/docs/production/preventing-abuse#rate-limiting-requests

[TomDoFuture]

Will try it

[TomDoFuture]

Note though @DanRibbens that I have not set rateLimits whatsoever on my production server... Because I didn't know such a thing existed lmao.

Anyway, unless there is a default rateLimit, and that rateLimit is being exceeded due to interactions with the reverse proxy I odnt think that is the problem. But will try it anyway, will try it tmr.

But the docs are a bit ambiguous, I don't know if the trustProxy option enables requests going through nginx in general, whereas by default they are disabled all together, or it increases the limit for the ratelimit. The docs kind of imply it does the latter, but explicitly states the former.

[TomDoFuture]

Alright just tried it now, doesn't work unfortunately

[jmikrut]

I don't think this is related to trustProxy—but I can say that every Payload instance we've ever deployed works perfectly with an nginx reverse proxy (including req, req.user, etc), so I'm thinking it's just something with how your setup is configured.

I'm going to convert this to a discussion, but if you can share your nginx config, maybe we can identify the problem!

[TomDoFuture]

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    #access_log  /var/log/nginx/host.access.log  main;

    location /admin {
        proxy_pass http://payload-cms:5000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
    }

    location /api {
        proxy_pass http://payload-cms:5000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
    }

    location / {
        proxy_pass http://evcs-frontend:3000;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

the evcs-frontend and payload-cms names are used because those are the container process names in the docker compose

[TomDoFuture]

Ok guys I just realized... Its not the Nginx reverse proxy that was wrong, I turned off the nginx and went to the port and it still doesn't work.

Menaing, there is just plainly no request body for some odd reason

[TimHal]

I know I am late for this discussion, but if someone in the future stumbles upon this thread like I did:

Make sure that your PAYLOAD_PUBLIC_SERVER_URL is configured correctly without a port. I had indicated the port which caused some requests to randomly lose their req.user. I did not investigate the exact details of this behavior but changing

PAYLOAD_PUBLIC_SERVER_URL=https://cms.my-domain.com:3000

to

PAYLOAD_PUBLIC_SERVER_URL=https://cms.my-domain.com

might fix that problem.