Zugang über https funktioniert nicht

Bernd aus No

Hi

Ich betreibe ein Blog (WordPress in der Version 2.0.10) auf meinem Rechner zu Hause.
Über das Internet kann ich zugreifen und alle Funktionen aufrufen.

Ich hatte vor einiger Zeit versucht, auf die Version 2.5.1 umzusteigen.
Die Admin-Seiten waren aus dem Internet erreichbar, nicht aber die Normalseiten.

Die neuste Version 2.6 zeigt das gleiche Verhalten.

Der Zugang zu meinem Blog vom Internet aus ist etwas komplizierter, als es sich die Entwickler von WordPress wohl vorgestellt haben. Ich verwende einen Apache2-Server, der nur über https angesprochen werden kann.
Der Aufruf sieht wie folgt aus:
https://xxx.homeip.net/yyy/wordpress/

Der Apache-Server leitet den Request an eine Maschine in meinem Netz weiter mit der Direktive
ProxyPass /yyy/ http://192.168.100.250/yyy/
Der Request kommt in der Zielmaschine an und wird bearbeitet.
[size=8](Diese Technik verwende ich für unterschiedliche Benutzer und Tools wie SVN, MediaWiki und auch WordPress in der alten Version.)[/SIZE]

Das Problem entsteht dadurch, dass irgendwo in der Verarbeitungsfolge ab /yyy/wordpress/index.php aus der ursprünglichen URL https://... ein http://... wird.

In der Datenbank sind in der Tabelle wp_options 4 Einträge in der Spalte options_value,
die die Zeichenfolge https://xxx.homeip.net/yyy/wordpress/ enthalten.
Darunter sind auch 'siteurl' und 'home'.

Irgendwo im PHP-Kode wird für einzelne Komponenten einer Seite die URL neu zusammengesetzt und dabei das falsche Protokoll verwendet.

Ich habe im Kode viele Stellen gefunden, die auf 'home' und 'siteurl' referenzieren.
Leider habe ich nicht die Stelle finden können, die das Problem verursacht.

Wie gesagt, die Version 2.0.10 verhält sich, so wie ich es wünsche.

Kann mir jemand helfen?

Gruß
Bernd

Werbepost

Hallo!

Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
✔️ Deutsche Server & DSGVO-konform
✔️ Persönlicher Support (kein 0815-Ticket-System)

Mehr erfahren

Ammaletu

Hm, ich bin mir nicht sicher, ob Du das so zum Laufen kriegen wirst. Ein mit WP 2.2, glaube ich, eingeführtes Feature nennt sich "Canonical URL" und sorgt dafür, dass WP nur mit der in den Optionen eingetragenen URL aufgerufen werden kann. Mit dieser URL werden dann natürlich auch alle Adressen auf der Seite gebaut, die Links zu den Beiträgen, Kategorien etc. Alle anderen Aufrufe werden darauf umgeleitet.

Bei Dir steht nun die https-Adresse drin. Ich bin mir nicht sicher, ob beim Proxy-Pass intern ein neuer Request mit der neuen Adresse erstellt wird. In dem Fall solltest Du mal probieren, in den Optionen die http-Adresse einzutragen. So oder so, schaue mal nach, welche Weiterleitungen WP ausführt, z.B. mit dem "LiveHTTPHeaders"-AddOn im Firefox. Da sollte sich schon herausfinden lassen, was genau passiert.

Bernd aus No

Hi Ammaletu

Ich habe bei den Add-Ons ein Tool gefunden, dass sich als 'Header Monitor' meldet.
Es zeigt jedoch, egal mit welcher Einstellung, keine Infos zu einem Aufruf (auch bei anderen Seiten nicht). Habe ich das falsche Add-on erwischt?

Im WordPress habe ich unter den allgemeinen Einstellungen zwei Optionen, die WordPress-
Adresse (URL) und Blog-Addresse (URL) heißen. In beiden Fällen habe ich https://xxx.homeip.net/yyy/wordpress/ stehen. Diese Optionen gibt es schon in der Version 2.0.10. Gibt es noch eine Stelle? Hattest Du eine andere Option gemeint?

Gruß
Bernd

codestyling

Hier mal ein Ausschnitt aus meinem SSL Reverse Proxy:

Code

<IfModule setenvif_module>
        BrowserMatch ".*MSIE.*" \
                 nokeepalive ssl-unclean-shutdown \
                 downgrade-1.0 force-response-1.0
    </IfModule>


    # WICHTIG! Aktiviert die SSL Unterstützung
    SSLProxyEngine On


    # Regeln zum umleiten auf den internen Server
    ProxyPass / http://testserver1/
    ProxyPassReverse / http://testserver1/
    
    # Diese Regeln sorgen für das Parsen und Umschreiben der URL’s in HTML Seiten
    #SetOutputFilter proxy-html
    #ProxyHTMLURLMap https://www.domain.de/ http://testserver1/
    #ProxyHTMLExtended On


    # WICHTIG! Deaktiviert die gzip-Kompression - ohne funktioniert das URL Rewriting nicht
    RequestHeader unset Accept-Encoding


    ErrorLog logs/extern-error_log
    CustomLog logs/extern-access_log common

Alles anzeigen

Evtl. kannst du auch noch die Regel zum Umschreiben der URL aktivieren. Warum du den lokalen Server per HTTPS definierst, verstehe ich nicht. Der lokale Server mit WP sollte über HTTP Protokoll lokal gehen und erst der Proxy macht hin- und rückzu HTTPS Umverpackung draus.

Ammaletu

Codestylings Antwort ist mit Sicherheit zielführender als meine, aber der Vollständigkeit halber: Ich meinte dieses Add-On:
mozdev.org - livehttpheaders: index

Damit kann man sehr schön mitverfolgen, wenn Umleitungen passieren, und sieht da manchmal das Problem auch direkt dran.

Bernd aus No

Meine Apache2-Konfiguration auf dem Rechner zum Internet sieht so aus (https
über Port 443):

Code

<IfModule mod_proxy.c>
  <Proxy *>
    Order allow,deny
    Allow from all
  </Proxy>


  ProxyRequests off
  ProxyPass /yyy/ http://192.168.100.250/yyy/
  ProxyPass /yyyWiki/ http://192.168.100.250/yyyWiki/
  ProxyPass /yyysvn/ http://192.168.100.250/yyysvn/
</IfModule>

Alles anzeigen

Auf der Maschine in der DMZ (192.168.100.250) steht in der Apache2-
Konfiguration für die ersten zwei Verweise je eine Alias/Directory-Directive.
Für den dritten Verweis habe ich eine Location-Directive verwendet.

Das Wiki und SVN funktionieren sehr gut und auch WordPress in der alten Version.

Ich habe mal die Vorschläge von von 'codestyling' probiert. Die Blöcke

Code

# Diese Regeln sorgen für das Parsen und Umschreiben der URL’s in HTML Seiten
    SetOutputFilter proxy-html
    ProxyHTMLURLMap https://xxx.homeip.net/ http://192.168.100.250/
    ProxyHTMLExtended On

und

Code

# WICHTIG! Deaktiviert die gzip-Kompression - ohne funktioniert das URL Rewriting nicht
    RequestHeader unset Accept-Encoding

funktionieren nicht - sie führen zu Fehlermeldungen beim (re)start des Apache-
Servers. Wahrscheinlich muss ich dazu noch Module laden.

Die Zeilen

Code

SSLProxyEngine On

und

Code

ProxyPass /yyy/ http://192.168.100.250/yyy/
    ProxyPassReverse /yyy/ http://192.168.100.250/yyy/

haben alleine aber nicht zum Erfolg geführt.

Es folgt noch ein 'Mitschnitt' Vom Tool, das Ammaletu empfohlen hat.

Code

https://xxx.homeip.net/yyy/wordpress/


GET /yyy/wordpress/ HTTP/1.1
Host: xxx.homeip.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4c27c762cc9d5f6ac75be4686a7b3e03=admin%7C1217710221%7C58cc5e27d16f30fda805219318531a9d
If-Modified-Since: Thu, 31 Jul 2008 20:50:21 GMT
Authorization: Basic QmFzaXM6YmFzaXM=


HTTP/1.x 301 Moved Permanently
Date: Thu, 31 Jul 2008 20:51:18 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8+etch11
X-Powered-By: PHP/5.2.0-8+etch11
X-Pingback: https://xxx.homeip.net/basis/wordpress/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Thu, 31 Jul 2008 20:51:18 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Location: http://xxx.homeip.net/basis/wordpress/
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Via: 1.1 xxx.homeip.net
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive

Alles anzeigen

Interessant ist die 6. Zeile von unten. Hier wird der Fehler dokumentiert.

Gruß
Bernd

Willkommen! Melden Sie sich an oder registrieren Sie sich.

Zugang über https funktioniert nicht

Jetzt mitmachen!