WordPress hinter Reverse-Proxy

Jetzt wollte ich “mal schnell” ein Worpress einrichten. Mit docker geht das ja jetzt alles super einfach.
Stimmt auch, aber leider nur im Prinzip.

Was zu meiner momentanen Lösung gehört:

  1. auf meinem “produktiv”-Docker-Host (den ich via https://www.tutum.co/ verwalte – nebei: sehr empfehlenswert):
    • folgender Service-Stack:
      mysql:
       image: 'mysql:latest'
       environment:
       - MYSQL_ROOT_PASSWORD=xxxxx
       restart: always
       roles:
       - global
       sequential_deployment: true
       tags:
       - prod
       volumes:
       - '/opt/wordpress/var_lib_mysql:/var/lib/mysql'
       - '/etc/localtime:/etc/localtime'
       - '/etc/timezone:/etc/timezone'
      wordpress:
       image: 'dsteinkopf/wordpress:latest'
       links:
       - mysql
       ports:
       - '8082:80'
       restart: always
       roles:
       - global
       sequential_deployment: true
       tags:
       - prod
       volumes:
       - '/opt/wordpress/var_www_html:/var/www/html'
       - '/etc/localtime:/etc/localtime'
       - '/etc/timezone:/etc/timezone'
    • Ich verwende das “offical” mysql-Image. Das docker-Image “tutum/mysql/ klappt nicht (so gut), weil sich dann das wordpress-Image nicht so reibungslos mysql username und pw etc. via docker-Verlinkung holen kann.
    • Ich habe ein eigenes WordPress-Docker-Image gebaut, dessen Dockerfile (siehe github) nur aus “FROM wordpress” besteht. (Es ist also identisch zum “official” wordpress-Image – und ist derzeit WordPress 4.4)
      Grund: Das ist die einzige Möglichkeit, die ich kenne, bei Docker-Hub einen Webhook einzutragen, der mir bei Tutum das Image automatisch von dort neu holt und installiert.
  2. Ein Apache auf einem “echten” (naja virtuellen) Host.
    • Diese macht die SSL-Terminierung.
    • Das Zertifikat habe ich von Letsencrypt vollautomatisch holen lassen – mit Hilfe von
      ./letsencrypt-auto --redirect --rsa-key-size 4096 --domains nerdblog.steinkopf.net
    • Die Apache-Config sieht bei meinen anderen Hosts im Kern immer nur so aus:
      RewriteEngine On
      ProxyRequests Off
      ProxyPass / https://mydockerhost.steinkopf.net:x8082x/
      ProxyPassReverse / https://mydockerhost.steinkopf.net:x8082x/
    • Bei WordPress reicht das nicht. Einiges googeln hat mir den Eindruck verschafft, dass WordPress für diesen “Betriebsmode” nicht wirklich gebaut wurde. Ich habe mich mehrfach ausgesperrt und nicht das Prinzip der Redirects verstanden. Vielleicht findet sich das genaue Verständnis ja noch.
    • Wenn man sich durch eintragen falscher Werte in der WP-Konfig in “” oder “” aussperrt kann mit sich retten mit einträgen in der wp-config.php:
      define('WP_SITEURL', 'https://nerdblog.steinkopf.net/');
      define('WP_HOME', 'https://nerdblog.steinkopf.net/');
  3. “Lösung” (fast) für das Reverse-Proxy-Problem:
    • In der wp-config.php:
      if (isset($_SERVER["HTTP_X_FORWARDED_FOR"])) {
          $_SERVER['REMOTE_ADDR'] = $_SERVER["HTTP_X_FORWARDED_FOR"];
      }
    • In der Apache-Config:
      
          ProxyHTMLEnable On
          ProxyHTMLExtended On
      
          ProxyHTMLLinks a href
          ProxyHTMLLinks area href
          ProxyHTMLLinks link href
          ProxyHTMLLinks img src longdesc usemap
          ProxyHTMLLinks object classid codebase data usemap
          ProxyHTMLLinks q cite
          ProxyHTMLLinks blockquote cite
          ProxyHTMLLinks ins cite
          ProxyHTMLLinks del cite
          ProxyHTMLLinks form action
          ProxyHTMLLinks input src usemap
          ProxyHTMLLinks head profile
          ProxyHTMLLinks base href
          ProxyHTMLLinks script src for
          ProxyHTMLLinks iframe src
      
          RequestHeader unset Accept-Encoding
      
          ProxyHTMLURLMap /wp-admin/ /wp-admin/
          ProxyHTMLURLMap \/wp-admin\/ \/wp-admin\/
          ProxyHTMLURLMap https://nerdblog.steinkopf.net/ https://nerdblog.steinkopf.net/
          ProxyHTMLURLMap https://nerdblog.steinkopf.net https://nerdblog.steinkopf.net
       
      
       ProxyPassReverseCookieDomain mydockerhost.steinkopf.net nerdblog.steinkopf.net
       ProxyPassReverseCookiePath / /
    • Anmerkungen:
  4. Offene Probleme:
    • Themes, die das img-Tag mit “usemap” benutzen, funktionieren nicht, da das mod_proxy_html mit ProxyHTMLLinks in der “usemap” immer nur den ersten Link anpasst, weil es vermutlich den Rest des Attributs als zum ersten Link gehörend betrachtet.
    • In Mails die verschickt werden, enhalten noch den internen Link. 🙁 Wer sollte das auch korrigieren? Der Reverse-Proxy kommt ja hier gar nicht “vorbei”.
    • Beim Theme-Preview wird auch noch die interne URL verwendet. (Zum Bearbeiten des Theme gehe auch also direkt auf die intern URL…)
    • Alle Plugins (z.B. Sharing-Plugins), die die Wordpress-URL an andere Dienste weiter geben, benutzen auch die falsche interne.

5 thoughts on “WordPress hinter Reverse-Proxy

  1. Ein weiteres Stück besser würde es durch Verwendung des mod_substitute und

            AddOutputFilterByType SUBSTITUTE text/html application/rss+xml text/plain text/xml text/html;charset=utf-8
            AddOutputFilter SUBSTITUTE php
            Substitute "s|https://nerdblog.steinkopf.net|https://nerdblog.steinkopf.net|i"
            Substitute "s|https:././mydockerhost.steinkopf.net:8082|https:\/\/nerdblog.steinkopf.net|i"
    
  2. Weitere Verbesserung:

    • In wp-config:
      define('WP_SITEURL', 'https://nerdblog.steinkopf.net/');
      define('WP_HOME', 'https://nerdblog.steinkopf.net/');
      
    • In der function.php des Theme:
      remove_filter('template_redirect','redirect_canonical');
      
    • im Reverse-Proxy:
      Header add X-Forwarded-Proto "https"
      RequestHeader set X-Forwarded-Proto "https"
      
    1. Das war tatsächlich auch bei mir “Gefummel” bis es lief. Inzwischen setze ich den Proxy, wie hier beschrieben, nicht mehr ein. Ich setze nun auf Kong+Konga.

      Was hast Du denn für ein Problem?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert