Closed evgeni closed 1 month ago
This is rather interesting because REMOTE_USER comes from django:
https://docs.djangoproject.com/en/5.0/howto/auth-remote-user/
I imagine there are a lot of django users using gunicorn. Maybe it's worth filing a django issue and see how they proceed?
It is and it isn't ;-) (You'll notice, I had a ton of fun with that).
REMOTE_USER
as Django wants it is an environment variable, not an HTTP header. That variable usually gets set by WSGI/whatever after handling auth.
In our case, auth is done by the frontend Apache/NGINX, which can only communicate to WSGI/Django via headers.
In the linked docs, there is a warning, where they say:
Since the HTTP headers X-Auth-User and X-Auth_User (for example) both normalize to the HTTP_X_AUTH_USER key in request.META, you must also check that your web server doesn’t allow a spoofed header using underscores in place of dashes.
No REMOTE_USER
anymore ;-)
Gunicorn is working on making this a bit more user-friendly in https://github.com/benoitc/gunicorn/pull/3192, by making it configurable which "illegal" headers get accepted from a "trusted" proxy.
Version any
Describe the bug https://docs.pulpproject.org/pulpcore/authentication/webserver.html#webserver-auth-with-reverse-proxy says:
But since gunicorn 22.0 (more precisely https://github.com/benoitc/gunicorn/commit/72b8970dbf2bf3444eb2e8b12aeff1a3d5922a9a/ https://github.com/benoitc/gunicorn/issues/2799) headers with underscores are forbidden by default.
If the docs would use a dash, so
proxy_set_header REMOTE-USER …
things would work :)Additional context Grant made me file this, and I did not want to post a screenshot of our colorful conversation ;)