#36862 closed Cleanup/optimization (fixed)
Clarify RemoteUserMiddleware usage and deployment requirements under ASGI
| Reported by: | Natalia Bidart | Owned by: | Jacob Walls |
|---|---|---|---|
| Component: | Documentation | Version: | 6.0 |
| Severity: | Normal | Keywords: | RemoteUserMiddleware asgi |
| Cc: | Triage Stage: | Ready for checkin | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
The current RemoteUser docs explains the trust model assuming a front-end web server that securely sets REMOTE_USER env var, but it does not clearly address ASGI deployments where Django may be the direct HTTP endpoint ( uvicorn, daphne examples). This can lead readers to assume that enabling RemoteUserMiddleware under ASGI without a reverse proxy is safe.
The docs should explicitly state that RemoteUserMiddleware assumes a trusted upstream that sets or strips the relevant header, and that running ASGI servers directly on the Internet without such a proxy will allow clients to inject identity headers. This is a documentation clarification only and does not change behavior.
Change History (18)
comment:1 by , 3 months ago
| Triage Stage: | Unreviewed → Accepted |
|---|
follow-up: 3 comment:2 by , 3 months ago
comment:3 by , 3 months ago
Replying to Kundan Yadav:
can i work on this issue ?
You are welcome to work on this ticket. That said, please note that this is not a straightforward issue and requires strong familiarity with ASGI and the REMOTE_USER authentication mechanism.
Also, please avoid relying on LLMs to drive your contribution, and ensure that you have carefully read the contributing documentation we have shared. In recent submissions, we have noticed that the code and documentation style do not fully align with the guidelines outlined in the Django coding style documentation. While some checks are automated, others are not. We therefore expect contributors to manually review their work and ensure it follows the documented conventions before submitting it for review.
comment:4 by , 3 months ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:6 by , 2 months ago
| Cc: | removed |
|---|---|
| Has patch: | unset |
comment:7 by , 6 weeks ago
Hi, I’d like to take this up, since the owner of the ticket has not produced a patch yet and there have been no formal updates regarding the ticket.
comment:8 by , 6 weeks ago
Vizzard, the experience from #36750 hasn't given me the confidence that you can handle multiple tickets at a time, so I'd prefer that you wait until we bring that one to completion.
comment:9 by , 5 weeks ago
Hello Jacob, since #36750 is completed, can I take this ticket up with your permission?
comment:10 by , 5 weeks ago
| Cc: | added |
|---|
comment:11 by , 2 weeks ago
| Owner: | changed from to |
|---|
Now that I close more duplicate reports about this more often than I consume hot meals, if you don't mind Vizzard, I'll going to assign to myself to put it on a critical path.
comment:14 by , 5 days ago
| Triage Stage: | Accepted → Ready for checkin |
|---|
can i work on this issue ?