django - cert - ssl free

Django @login_required descartando https

Question

Estoy tratando de probar mi aplicación Django localmente usando SSL. Tengo una vista con el decorador @login_required . Entonces, cuando pulso /locker , me redireccionan a /locker/login?next=/locker . Esto funciona bien con http.

Sin embargo, cada vez que uso https, el redireccionamiento de alguna manera elimina la conexión segura, entonces obtengo algo como https://cumulus.dev/locker -> http://cumulus.dev/locker/login?next=/locker

Si voy directamente a https://cumulus.dev/locker/login?next=locker la página se abre correctamente a través de una conexión segura. Pero una vez que ingreso el nombre de usuario y la contraseña, vuelvo a http://cumulus.dev/locker .

Estoy usando Nginx para manejar SSL, que luego habla con runserver . Mi configuración nginx es

upstream app_server_djangoapp {
server localhost:8000 fail_timeout=0;
}
server {
listen 80;
server_name cumulus.dev;
access_log /var/log/nginx/cumulus-dev-access.log;
error_log /var/log/nginx/cumulus-dev-error.log info;
keepalive_timeout 5;
# path for static files
root /home/gaurav/www/Cumulus/cumulus_lightbox/static;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://app_server_djangoapp;
break;
}
}
}
server {
listen 443;
server_name cumulus.dev;
ssl on;
ssl_certificate /etc/ssl/cacert-cumulus.pem;
ssl_certificate_key /etc/ssl/privkey.pem;
access_log /var/log/nginx/cumulus-dev-access.log;
error_log /var/log/nginx/cumulus-dev-error.log info;
keepalive_timeout 5;
# path for static files
root /home/gaurav/www/Cumulus/cumulus_lightbox/static;
location / {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Ssl on;
proxy_set_header Host $http_host;
proxy_redirect off;
if (!-f $request_filename) {
proxy_pass http://app_server_djangoapp;
break;
}
}
}

Answer 1

Django se ejecuta en HTTP plano solo detrás del proxy, por lo que siempre lo usará para construir URL absolutas (como redirecciones), a menos que lo configure cómo ver que la solicitud de proxy fue hecha originalmente a través de HTTPS.

A partir de Django 1.4, puede hacer esto usando la configuración SECURE_PROXY_SSL_HEADER . Cuando Django ve el encabezado configurado, tratará la solicitud como HTTPS en lugar de HTTP: request.is_secure() devolverá true, se generarán https:// URLs, y así sucesivamente.

Sin embargo, tenga en cuenta las advertencias de seguridad en la documentación: debe asegurarse de que el proxy reemplace o elimine el encabezado de confianza de todas las solicitudes de clientes entrantes, tanto HTTP como HTTPS. Su configuración nginx anterior no hace eso con X-Forwarded-Ssl , por lo que es spoofable.

Una solución convencional para esto es establecer X-Forwarded-Protocol en http o https , según corresponda, en cada una de las configuraciones de proxy. Luego, puede configurar Django para que lo busque usando:

SECURE_PROXY_SSL_HEADER = (''HTTP_X_FORWARDED_PROTOCOL'', ''https'')