Hallo allen,
es geht hier darum, das BE dauerhaft per SSL zu bedienen (Admin + Redakteure) über https://ssl-account.com/my-domain.tld/contao-install/contao; der normale Besucher kann und soll die Seite wie üblich aufsuchen via http://my-domain.tld/contao-install/. (Beim Wechsel zwischen http und https muss die Session vorerst nicht zwingend erhalten bleiben). Ein Jahr nach Snowden sollte es jedenfalls jedem klar sein, dass es keine Paranoia ist, seinen Admin-Zugang nicht im Klartext durch's Netz zu schicken...
Nach wie vor scheint Contao dieses Problem aber eher stiefmütterlich zu behandeln. Zumindest die Arme-Leute Version von SSL ohne eigenes oder teures CA-Cert, sondern via SSL-Proxy des Providers.
- Basisinstallation - alles OK
- contao-3.2.13-LTS als auch contao-3.3.4
- getestet mit PHP 5.3/5.4 - sowohl mod-php als auch cgi.
- Contao-Check 7.3 - alles OK
- ssl-account.com in BE eingetragen bei System->Einstellungen->SSL-Proxy-Domain
Nach mehreren erfolglosen Anläufen und auch nach intensiver Befragung des vorhandenen Forenmaterials und github habe ich keine funktionierenden Lösung gefunden, um Zugang via SSL-Proxy hinzubekommen und bezweifle, dass dies mit dem aktuellen Code jemandem gelungen ist.
Nach einiger Recherche im Code bin ich dann auf die Ursache gestoßen:
Beim Setzen der Cookies wird der Cookie-Path genauso gesetzt, wie wenn der Zugriff ohne SSL-Proxy erfolgen würde. Es wird immer nur Bezug genommen auf TL_PATH und dessen Abkömmlinge. Dass der ursprüngliche Domainname beim SSL-Proxy zum Teil des Pfades wird, wird zwar beim Erzeugen der URLs beachtet, nicht aber beim Setzen der Cookies.
Das korrekte Setzen des Cookie-Path für die verschiedenen Konstellationen wird hier bereits beschrieben:
https://github.com/contao/core/issue...omment-2949206
Allerdings bringt es nach meiner Erfahrung überhaupt nichts, mit Pfadangaben in localconfig.php oder pathconfig.php herumzuspielen, da dann zwar möglicherweise der Cookie-Path stimmt, dafür dann aber andere Path-Referenzen völlig daneben laufen und es das CMS damit zerreißt.
Nach meiner Beobachtung müssen zwei Cookies mit korrektem Pfad gesetzt werden: PHPSESSID sowie BE_USER_AUTH.
Im gesamten Core gibt es nur eine Stelle, an der diese Proxy-Thematik beachtet wird und das sind beim Zusammenbauen der URL in system/modules/core/library/Contao/Environment.php die lokalen Funktion httpXForwardedHost() in Zeile 286 sowie url() ca. in Zeile 308.
Beim Setzen der Cookies spielt der evtl. genutzte SSL-Proxy bislang keine Rolle.
So habe ich selbst mal ein wenig hemdsärmelig den erforderlichen Code nachgefügt - zumindest für mich funktioniert es - und wie gesagt: nur für das BE.
In system/initialize.php ca. Zeile 152
Code:
/**
* Start the session
*/
//@session_set_cookie_params(0, (TL_PATH ?: '/')); // see #5339
/* session path setting depend for use of ssl-proxy - see also TL_ROOT/system/modules/core/library/Contao/System.php Line 505 */
if ( $_SERVER["HTTP_X_FORWARDED_HOST"] ) {
$cookiePath = $_SERVER["HTTP_HOST"] . dirname($_SERVER["SCRIPT_NAME"]) . '/';
@session_set_cookie_params(0, $cookiePath); // see #5339
} else {
@session_set_cookie_params(0, (TL_PATH ?: '/')); // see #5339
}
In system/modules/core/library/Contao/System.php in der public static function setCookie Zeile 505 nach dem Code $strPath = TL_PATH ?: '/'; // see #4390 wie folgt ergänzt:
Code:
if ($strPath == '')
{
$strPath = TL_PATH ?: '/'; // see #4390
/* session path setting depend for use of ssl-proxy - see TL_ROOT/system/initialize.php Line 152*/
if ( $_SERVER["HTTP_X_FORWARDED_HOST"] ) {
$strPath = $_SERVER["HTTP_HOST"] . dirname($_SERVER["SCRIPT_NAME"]) . '/';
}
}
Ob der Code auch bei anderen SSL-Proxy-Anbietern so funktioniert, kann ich nicht sagen.
Auch ist es wirklich nur ein Workaround. Vielleicht könnte sich einer der Entwickler dessen noch mal mit annehmen, damit eine dauerhafte Lösung in den Code einfließt, der dann auch vernünftig über eine Config kontrolliert werden kann...
Lesezeichen