Opened 13 years ago
Closed 12 years ago
#16046 closed New feature (fixed)
Document best practices around using request.is_secure() in reverse proxy environments
Reported by: | Adam Nelson | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
As evidenced in these locations:
- #14597
- https://github.com/rossdakin/django-heroism
- http://packages.python.org/django-middleware-extras/usage.html
- http://yuji.wordpress.com/2008/08/15/django-nginx-making-ssl-work-on-django-behind-a-reverse-proxy/
- #6548
There is a need to document a best-practices way of handling an upstream django server (Gunicorn, etc...) behind a reverse proxy (Nginx, etc...) using the request.is_secure() method.
Change History (4)
comment:1 by , 13 years ago
Triage Stage: | Unreviewed → Someday/Maybe |
---|
comment:2 by , 13 years ago
django-heroism uses two headers, 'X-Forwarded-Protocol' for what you say, and then X-Magic-Header with a secret value for validation that the headers have not been tampered with. This solves the problem you bring up.
comment:4 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Triage Stage: | Someday/Maybe → Accepted |
Type: | Cleanup/optimization → New feature |
As far as I can tell, 61f0aff811aa596fa62136852c59d47f988d1185 covers this.
There's extensive documentation for the SECURE_PROXY_SSL_HEADER
setting.
I'm going to accept as 'Maybe/Someday', on the basis that I don't know that there is a 'best-practices way'.
The most commonly used method is to add a header like X-Forwarded-Protocol, but AFAICS it isn't so easy to configure common webservers to ensure that this header is not passed on if the request is not HTTPS i.e. stripping headers seems to be much harder. Without this ability, there is a big flaw in this method, because a MITM attack could add the header, fooling the web app into believing the request is secure.
It is possible to use a custom header which is not guessable by 3rd parties. However, this is problematic. 1) It means that we have a piece of webserver configuration information that is now a secret, so you now have to keep your webserver config secret. 2) It is insecure in shared hosting scenarios, and these are pretty common with Django hosting e.g. WebFaction.
We don't want to document a best-practice that is actually impractical. If you can point us to something that is actually a good way of doing it, please do so.