SSL Redirect-Schleife mit WordPress HTTPS Plugin

Ich verwende WordPress in einem NginX-Server, der an einen Apache-Server weitergeleitet wird, der die Seiten bedient. Kürzlich wollten wir die Verwendung von SSL zumindest im Admin-Bereich erzwingen, also installierten wir das WordPress HTTPS- Plugin. Die Serverabschnitte in NginX sind richtig konfiguriert, aber wenn ich die Option “SSL for admin erzwingen” aktiviere, falle ich in eine Umleitungsschleife.

Ich glaube nicht, dass es ein Cookie-Problem ist. Wenn Sie mehr Informationen benötigen, werde ich es Ihnen weitergeben.

Solutions Collecting From Web of "SSL Redirect-Schleife mit WordPress HTTPS Plugin"

Ich habe kürzlich mit einem ähnlichen Problem gekämpft, deshalb werde ich ein paar zusätzliche Informationen für Leute anbieten, die nach dieser Frage suchen.

  1. Der erste Schritt, den Sie ausführen sollten, wenn Sie versuchen, SSL für den Administrator Ihrer Site zu erzwingen, besteht darin, den statementen im Codex zu folgen. Dies bedeutet, dass Sie die FORCE_SSL_ADMIN Option in Ihrer wp-config.php-Datei definieren müssen.
  2. Achten Sie darauf, die Warnung im Codex zu beachten, dass diese Bearbeitung über dem /* That's all, stop editing! Happy blogging. */ /* That's all, stop editing! Happy blogging. */ /* That's all, stop editing! Happy blogging. */ Linie.
  3. Es gibt viele mögliche Gründe, warum dies Ihnen eine Redirect-Schleife geben könnte, aber sie alle is_ssl() die Tatsache, dass WordPress ‘ is_ssl() function false is_ssl() . Beispielsweise können Sie hinter einem Reverseproxy ausgeführt werden, das SSL-Offloading durchführt. Wenn dies der Fall ist, geben Ihre Benutzer https://yourwordpresssite , aber der SSL-Offloader übernimmt die Entschlüsselung. Wenn Ihr Server die Anfrage empfängt, ist die Anfrage nicht länger SSL und Ihr Server sieht http://yourwordpresssite . Wenn Sie hier feststecken, hat der Codex gute Ratschläge, vorausgesetzt, Ihr Reverse-Proxy ist richtig konfiguriert. Siehe die statementen hier: (http://codex.wordpress.org/Administration_Over_SSL#Using_a_Reverse_Proxy).

Wenn das immer noch nicht funktioniert, setzt Ihr HTTP_X_FORWARDED_PROTO möglicherweise den HTTP_X_FORWARDED_PROTO Header nicht. Leider ist nichts davon standardisiert, und es gibt mehr als eine Möglichkeit anzugeben, dass SSL-Offloading stattgefunden hat. Die von unserem Lastenausgleichsmodul (Citrix Netscaler) verwendete Methode ist die von Microsoft erstellte Kopfzeile Front-End-Https . Sie können diesen Header als einen der üblichen nicht standardmäßigen Antwortheader sehen, die hier in Wikipedia aufgelistet sind: (http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Common_non_standard_response_headers). Beachten Sie, dass zu dem Zeitpunkt, zu dem Ihr Server diese Kopfzeile sieht, es wie HTTP_FRONT_END_HTTPS . Beachten Sie auch, dass Netscaler diesen Header standardmäßig nicht sendet – Sie müssen ihn konfigurieren, um den Header hinzuzufügen. Dies ist hier dokumentiert, und es gibt eine schöne Video-Demo, wie man es hier macht .

Da wir unsere gesamte Website ausschließlich mit HTTPS betreiben, entschied ich mich schließlich dafür, das WordPress-https-Plugin zu verwenden, das Edge-Cases gut verarbeitet (wie andere WordPress-Plugins, die fest codierte http: // URLs haben) wird Warnungen auf Ihren sicheren Seiten verursachen). Ich habe das Plugin gepatcht, um den Header HTTP_FRONT_END_HTTPS zu erkennen und HTTP_FRONT_END_HTTPS einen Patch an den Autor, so dass es irgendwann von diesem Plugin unterstützt werden sollte.

Viel Glück!

Der Check für is_ssl() ist nicht wirklich der beste in WP. Sie können dieses mu-plugin benutzen , um eine bessere Kontrolle zu bekommen. Dann halten Sie sich einfach an die Empfehlungen des Kodex .

Ad the WordPress HTTPS-Plugin) Ich würde nicht zu viel auf dieses Plugin zählen, wenn ich den Kofferraum betrachte …

Mu-Plugins

MU-Plugins im Codex

Ich habe dieses Problem für mich getriggers, indem ich auf das CDN (Cloudflare) der Website gegangen bin und den SSL-Modus auf “voll” gestellt habe

Zuvor war es auf “flexibel”, was vermutlich die Mischung von HTTP- und HTTPS-Anfragen verursachte oder erlaubte.

Obwohl ich das CDN im “Entwickler” -Modus hatte (was meiner Ansicht nach das CDN daran hinderte, die Website zu beeinträchtigen), hatte die SSL-Einstellung während der Problembehandlung weiterhin Auswirkungen.