Nachdem mein Server-Setup letztens nach dem Umzug auf neue Hardware ja etwas umgebaut wurde, hatte ich mit meinem Blog ein wenig zu K\u00e4mpfen, da das Blog aus Performance-Gr\u00fcnden nur interne IPs mit HTTP-Requests sieht (die externen IPs sind via Header auch sichtbar). Entsprechend war das Blog auch bei Abruf \u00fcber SSL st\u00e4ndig der Meinung die Resourcen mit HTTP, also ohne Verschl\u00fcsslung abzurufen.<\/p>\n
Ursache f\u00fcr dieses Ph\u00e4nomen ist, dass die Funktion is_ssl() von WordPress nicht mit Reverse-Proxy-Konfigurationen kann, und daher das Request-Schema der internen Verbindung f\u00fcr die Entscheidung heranzieht. Dies l\u00e4sst sich aber leicht \u00e4ndern.<\/p>\n
Mit zwei kleinen \u00c4nderungen kann man WordPress vorgaukeln, dass die interne Verbindung HTTPS nutzt. Hierzu f\u00fcgt man in seiner wp-config.php folgende Zeilen vor dem Include der wp-settings.php ein:<\/p>\n
\r\nif (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {\r\n $_SERVER['HTTPS']='on';\r\n}\r\n<\/pre>\nNun muss man im Reverse-Proxy nur noch f\u00fcr eine korrekte Weitergabe der Information zum Protokoll der urspr\u00fcnglichen Verbindung sorgen. In meinem Fall mit nginx ist das exakt eine Zeile:<\/p>\n
\r\nproxy_set_header X-Forwarded-Proto $scheme;\r\n<\/pre>\nUnd siehe da: Nun klappt das auch mit dem WordPress und SSL.<\/p>\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"