Opened 13 years ago

Closed 11 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


As evidenced in these locations:

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 Changed 13 years ago by Luke Plant

Triage Stage: UnreviewedSomeday/Maybe

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.

comment:2 Changed 13 years ago by Adam Nelson

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:3 Changed 12 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:4 Changed 11 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed
Triage Stage: Someday/MaybeAccepted
Type: Cleanup/optimizationNew feature

As far as I can tell, 61f0aff811aa596fa62136852c59d47f988d1185 covers this.

There's extensive documentation for the SECURE_PROXY_SSL_HEADER setting.

Note: See TracTickets for help on using tickets.
Back to Top