force_ssl_admin () verursacht Probleme mit Vorschaulinks

Ich habe vor kurzem meine WordPress-Website aktiviert, um ein SSL-Zertifikat für Administrations- / Anmeldeseiten zu verwenden. Ich verwende das Plugin W3 Total Cache mit meinem Content Delivery-Netzwerk. Ich habe festgestellt, dass wenn ich alle Beiträge sehe und auf den Vorschau-Link klicke, er mich auf eine immer noch gesicherte Webseite schickt, die NICHT für die Admin-Seiten relevant ist. Dies verursacht Probleme mit gemischten Inhalten, die von meinem CDN (unsicher) und meinem Webserver (sicher) empfangen werden.

Gibt es eine RewriteRule, die ich verwenden könnte, die das beheben würde oder habe ich eine Einstellung verpasst, die dies nicht verursachen sollte?

Ich möchte HTTPS nicht auf ANY-Front-End-Seiten verwenden, außer auf der Anmeldeseite. Auch wenn ich Posts in der Vorschau sehe, da dies unnötig ist und Probleme verursacht.

Irgendeine Hilfe?

Solutions Collecting From Web of "force_ssl_admin () verursacht Probleme mit Vorschaulinks"

WordPress hat eine Reihe von impliziten Annahmen in Bezug auf die Verwendung von SSL. Insbesondere, wenn Sie force_ssl_admin verwenden und die “Vorderseite” Ihrer Site die gleiche Domain hat wie die “Rückseite”, wird davon ausgegangen, dass Ihre gesamte Site tatsächlich über http oder https erreichbar ist.

Dies geschieht an ein paar verschiedenen Orten. Vor allem lädt der Theme Customizer absichtlich das Vorschaufenster (die Frontend-Ansicht Ihrer Site) mit SSL, wenn force_ssl_admin aktiviert ist und die Domain der Site übereinstimmt. Der Vorschau-Link auf dem Post-Bildschirm wird relativ sein und somit auch auf eine SSL-Seite gehen.

Also, die kurze Antwort ist, dass dies per Design ist und es wird wahrscheinlich nicht bald von WordPress core behoben werden. Es wird erwartet, dass Ihre Website über SSL funktioniert, wenn Sie SSL überall verwenden und es so versucht. Wenn auf Ihrer Website noch etwas vorhanden ist, das aktiv verhindert, dass das Front-End über SSL funktioniert, ist es defekt. Und viele in der Gemeinde würden sagen, ja, das soll es tun.

Sie erstellen das Problem im Wesentlichen durch die willkürliche Aktion, SSL am Frontend zu verbieten. Sie müssen SSL nicht wirklich am Frontend erzwingen , aber aktiv zu verbieten, kann zu Sicherheitsrisiken führen. Wie wir das “vordere” und “hintere” Ende von WordPress definieren, ist zunächst etwas willkürlich. Wenn Sie wirklich Sicherheit wollen, dann muss es in der Lage sein, jede Seite auf der ganzen Seite mit SSL zu laden, nicht nur das Zeug wp-admin.

Wenn Ihr CDN hier das Problem ist, weil sie keine https-Fähigkeit haben, sollten Sie ein anderes CDN in Erwägung ziehen, das HTTPS unterstützt, oder den Code nur über HTTP-Verbindungen vom CDN ändern und die lokalen Versionen von Dateien für HTTPS verwenden. Das ist jedoch eine kurzfristige Lösung. Bei einer Reihe von CDNs können Sie auf einen von Ihnen gesteuerten Domänennamen verweisen, und Sie können dann SSL für diesen Domänennamen einrichten. Wenn Sie also ein Zertifikat für example.com haben, könnten Sie auf cdn.example.com verweisen, dann könnten sie Ihr Zertifikat zum Sichern dieser Verbindung verwenden. Oder was auch immer, verschiedene CDNs haben unterschiedliche Möglichkeiten, HTTPS zu unterstützen.

Auf lange Sicht bewegt sich das gesamte Web mehr und mehr zu 100% SSL. Neuere Protokolle wie SPDY (die in den meisten gängigen Browsern unterstützt werden) können die Übertragungsgeschwindigkeit dramatisch erhöhen und funktionieren erst wirklich bei SSL-Verbindungen. Mit immer mehr “gehackten” Seiten und den jüngsten NSA-Enthüllungen und allem anderen fallen unverschlüsselte Verbindungen schnell in Ungnade. Die meisten Ratschläge, die Sie heute bekommen werden, sind, nur in den sauren Apfel zu beißen und gezwungenes SSL über die gesamte Site zu gehen.