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: