Ich versuche, meine Django-App lokal mit SSL zu testen. Ich habe eine Sicht mit dem @login_required
Decorator. Wenn ich also /locker
ankreuze, werde ich zu /locker/login?next=/locker
weitergeleitet. Dies funktioniert gut mit http.
Wenn ich jedoch https verwende, wird die sichere Verbindung durch die Umleitung irgendwie unterbrochen, sodass ich etwas wie https://cumulus.dev/locker -> http://cumulus.dev/locker/login?next=/locker
Wenn ich direkt zu https://cumulus.dev/locker/login?next=locker
gehe, öffnet sich die Seite über eine sichere Verbindung. Aber sobald ich den Benutzernamen und das Passwort eingegeben habe, gehe ich zurück zu http://cumulus.dev/locker
.
Ich benutze Nginx, um das SSL zu behandeln, das dann mit runserver
redet. Meine nginx-Konfiguration ist
Django läuft auf reinem HTTP nur hinter dem Proxy, also wird es immer das verwenden, um absolute URLs zu erstellen (wie Weiterleitungen), es sei denn, Sie konfigurieren, wie die Proxy-Anfrage ursprünglich über HTTPS erstellt wurde.
Ab Django 1.4 können Sie dazu die SECURE_PROXY_SSL_HEADER
verwenden. Einstellung. Wenn Django den konfigurierten Header sieht, behandelt er die Anfrage als HTTPS anstelle von HTTP: request.is_secure()
gibt true zurück, https://
URLs werden generiert und so weiter.
Beachten Sie jedoch die Sicherheitswarnungen in der Dokumentation: Sie müssen sicherstellen, dass der Proxy den vertrauenswürdigen Header von allen eingehenden Clientanforderungen (HTTP und HTTPS) ersetzt oder entfernt. Ihre nginx-Konfiguration oben tut das nicht mit X-Forwarded-Ssl
, wodurch sie gefälscht wird.
Eine konventionelle Lösung besteht darin, X-Forwarded-Protocol
auf http
oder https
in jeder Ihrer Proxy-Konfigurationen zu setzen. Dann können Sie Django so konfigurieren, dass Sie Folgendes suchen: