Serving Django apps behind SSL with Nginx

Serving Django apps behind SSL with Nginx.md

Configuring Nginx to serve SSL content is straight forward, once you have your certificate and key ready:

server { 
    listen 443 default ssl;
    root /path/to/source;
    server_name mydomain;

    ssl_certificate      /path/to/cert;
    ssl_certificate_key  /path/to/key;


    client_max_body_size 10M;
    access_log /var/log/nginx/alog.log;
    error_log /var/log/nginx/elog.log;


    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass  http://unix:/sourcepath/run/app.sock;
    }

}

But you will find, as I did, that Django makes redirections from https to http URLs when you use an HttpResponseRedirect object.

When Django does a redirection, it composes an absolute URI based on the one in the request object. And the request object uses its method build_absolute_uri() to make this URI, which in turn calls another HttpRequest method, is_secure(), to check whether to use http or https.

OK, that was all an intro. The interesting bit I want to share is that this is_secure() method works differently under Django 1.3 or 1.4. Under 1.3 it only checks whether an environment variable named "https" exists and its value is "on":

def is_secure(self):
        return os.environ.get("HTTPS") == "on"

So if you want to make sure you serve secure URLs all the way, you need to setup that environment var.

But under 1.4 it does another check before doing that one. It looks for the HTTP header X-Forwarded-Proto, and if it is present, it returns True (https request). This header has to be added to in the Nginx configuration for the secure server so it is passed to gunicorn:

location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Forwarded-Proto $scheme
        proxy_pass  http://unix:/sourcepath/run/app.sock;
    }

NB X-Forwarded-Proto

I've wasted hours of my life trying to figure out why X-Forwarded-Protocol didn't work. Well its because at some point in time, either it worked or the collective consciousness of the Internet got it wrong and perpetuated this incorrect information. The correct proxy_set_header is in fact X-Forwarded-Proto. Hopefully this tidbit will save you from wasting hours of your life like I did.

@rivernews: thx for the follow up :D In my case I ended up using a custon header (X-Forwarded-Proto-Custom) and setting SECURE_PROXY_SSL_HEADER to read this custom header instead while I wait for the provider that deliver the first layer of Reverse Proxy to actually forward the headers needed. In your case you are right, the default headers should be alright without additional configuration ;)

@clemen glad to help!

Came here just to deeply thank all of you guys, thanks to your hours of pain I was able to solve this in 5 minutes ✨

@davewongillies I would ask for help on my specific configuration:
I have a Django application executed by gunicorn with an Nginx reverse proxy. Everything runs on the same Docker instance, run by Supervisord. Gunicorn runs on port 8000, Nginx runs on port 80.

The Nginx config is

server {
    listen      80;

    location /static/ {
        alias /home/app/static/static_assets/;
    }

    location /media-files/ {
        internal; # only the django instance can access this url directly
        alias /home/app/media/media_assets/;
    }

    location / {
        proxy_pass http://localhost:8000;
    }
}

I am trying to use the above solution to make OAuth2 work with Google. With the original configuration the error is as follows:

Error 400: redirect_uri_mismatch
The redirect URI in the request, http://localhost:8000/accounts/google/login/callback/, does not match the ones authorized for the OAuth client. To update the authorized redirect URIs, visit: https://console.developers.google.com/apis/credentials/oauthclient/${your_client_id}?project=${your_project_number}

If I add the configuration snippet I get the error below:

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_set_header X-Forwarded-Proto $scheme;

Code: unknown, Error: HTTPSConnectionPool(host='accounts.google.com', port=443): Max retries exceeded with url: /o/oauth2/token (Caused by ProxyError('Cannot connect to proxy.', NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f79207eb640>: Failed to establish a new connection: [Errno -2] Name or service not known')))

@rivernews Thanks I had the exact same issue! so with Kubernetes, actually NOT setting:
proxy_set_header X-Forwarded-Proto

in nginx was the solution, as kubernetes already sets this to https

thanks. your docs save my time alot!