Bei einer Analyse der Google-Keywords bin ich über einen interessanten Suchbegriff gestolpert: “php session mit prototype.js”. Da hat wohl jemand die ID der laufenden PHP Session für eine Abfrage benötigt. Mir stellen sich dabei die Fragen:
- Erledigt nicht der Browser die Übermittlung der Session ID?
- Und: was, wenn das mal nicht funktioniert?
Ganz klar, wenn im Hintergrund etwas übertragen wird, dann passiert das bei HTTP meist über den Protokoll-Header oder über Cookies (die selbst im Protokoll-Header kodiert werden). Aber was, wenn Cookies deaktiviert sind? Wie kommt dann die Session-ID vom Server zum Client und wieder vom Client zum Server zurück?
Fatal für jede Web 2.0 Anwendung, wenn die Übertragung der Session ID fehlschlägt. Zeit, das Problem mal unter die Lupe zu nehmen und ein kleines Testszenario aufzubauen. Ums einfach zu halten, greife ich nicht auf SimpleTest zurück, sondern baue das Testframework schnell per Hand.
Es besteht aus folgenden Dateien:
- session_main.php (Hauptseite)
- session_out.php (wird via Ajax nachgeladen)
- cookie_ctrl.php (Konfiguration zum An- und Abschalten des Session Cookies)
- prototype.js (Ajax-Handler und DOM-Zugriff)
- cookie.js (Cookie-Wrapper von Frank Nägler)
Mittels der cookie_ctrl.php hat man die Möglichkeit, das Senden des Cookies mit der Session ID abzuschalten. Damit können wir simulieren, ob der Client Cookies annimmt (oder nicht).
Die session_main.php startet eine Session, schreibt eine “geheime” Information in die Session und stellt eine rudimentäre HTML-Ausgabe zur Verfügung, die anzeigt, auf welchem Weg eine Ausgabe der “geheimen” Information erfolgt. Zu diesem Zweck wird via Ajax die session_out.php nachgeladen und der Inhalt angezeigt.
Es gibt drei Wege, um mittels Javascript an die PHP Session ID zu kommen:
- Das Cookie mit dem Namen “SID” wird ausgelesen
- Die ID wird mit PHP in eine Javascript-Variable generiert oder in ein DOM-Objekt geschrieben
- Der Querystring wird ausgewertet und der via GET übermittelte SID-Parameter ausgelesen
Ich bin der Meinung, dass die 3. Möglichkeit eher selten vorkommt. Das die Session ID in der URL übertragen wird, ist eher Praxis bei JSP-Portalen, bei Portalen die mit PHP realisiert sind habe ich das relativ selten beobachtet. Einen Vorteil hat es aber: Man weiß, das die Session ID an den Client übertragen wird und ankommt.
In meinem Test habe ich mich auf Methode 1 und 2 konzentriert. Hier sind die Ergebnisse bei eingeschaltetem Cookie:
Sobald man die Cookieunterstützung ausschaltet, sieht es wie folgt aus:
Wie man deutlich erkennt, kann in der zweiten Variante das Cookie weder von Javascript erkannt noch via Ajax genutzt werden. Kein Wunder, es ist ja auch ausgeschaltet ;-)
Was hingegen sehr zuverlässig funktioniert, ist das Auslesen über einen PHP String und das anschließende Übermitteln als GET-Variable mit dem Namen “SID”. Um die Zuverlässigkeit der URL-Übertragung zu erhöhen, habe ich zusätzlich in der Datei session_out.php geprüft, ob ein Parameter “SID” übertragen wird und wenn ja manuell die Session ID gesetzt:
if(isset($_GET["SID"]))
{
   session_id($_GET["SID"]);
}
session_start();
Wichtig ist hierbei, das das manuelle Setzen der Session ID vor dem Aufruf von session_start() erfolgt. Sonst wird (sofern die Session ID nicht korrekt erkannt wird) eine neue Session gestartet…
Download:
Alle Dateien gibt es zum Downloaden und Ausprobieren auf dem eigenen Testrechner oder Webspace. Wenn Du die zwei Varianten testest, denk daran nach dem Umstellen der cookie_ctrl.php eine komplett neue Browser-Instanz zu starten, weil sonst das Cookie erhalten bleibt.
Konkrete Anwendung:
Sergej hat fast zeitgleich einen ähnlichen Artikel zu diesem Thema geschrieben. Er beschreibt eine Lösung zum URL-Rewriting mit Javascript: Ist kein Cookie mit der Session ID gesetzt, wird die Seite neu geladen und zusätzlich die Session ID als Parameter angehängt.
