Session-IDs und W3C Validität |
Freitag, 28. November 2008
|
||
Arbeitet man mit Sessions (oder Sitzungen) hängt PHP automatisch die Session-ID hinter die URLs und Formulare, jedoch teilweise ohne dabei die Normen der W3C einzuhalten.
Eine sogenannte Session (oder Sitzung) ist ein Cookie, dass in dem Browser des Besuchers gespeichert wird. Darin enthalten ist eine ID-Nummer. Die benötigt man um z.B. Einstellungen auf der Seite zu speichern. Funktionsweise von Sessions Anstatt alle Einstellung direkt in einem Cookie zu speichern, wird dort nur die Session-ID gespeichert und die verweist auf eine entsprechende Datei auf dem Server in der dann die ganzen Einträge gespeichert werden. Eine solche Session kann man mit PHP z.B. folgendermaßen aufrufen: session_start(); Das Gute ist, dass solange das Cookie beim Nutzer gespeichert ist, diese Einstellung erhalten bleiben. Der Nutzer jedoch kann diese Session nicht auslesen, lediglich die Nummer - die ihn aber nicht weiterbringt. So könnte man duzende Informationen für den aktuellen Nutzer abspeichern, für ihn ist alles nur eine Session-ID. Sinnvolle Anwendungsgebiete wären z.B. das automatische Ausfüllen von einem Kommentar-Formular. Einmal die persönlichen Daten dort eingetragen, werden Sie beim nächsten Besuch automatisch hinzugefügt. Sessions ohne Cookies Die Sitzung wird mit einer Sitzungs-ID gespeichert und zwar in einem Cookie. Habe ich meine Cookies deaktiviert bedient sich PHP einer anderen Möglichkeit. Er fügt in jeden Link auf meiner Seite ein &PHPSESSID=1234567980 dazu. So werden dann die aktuellen Einstellungen auch auf der nächsten Seite gültig, da nun klar ist wie die Session-ID lautet. In Formularen gibt es eine ähnliche, automatische Ergänzung seitens PHP, die so aussieht: <input type="hidden" name="PHPSESSID" value="a25bfbbd1b756da04597c350c7c462bf" /> Durch diese automatischen Ergänzungen kann dann die Session-ID auch auf die weiteren Seiten übernommen werden, ohne das Cookies aktiviert sind. Das Problem mit Validatoren Es gibt Standards. Und PHP verstößt mit den Aktionen teilweise dagegen. Es ist zum Beispiel nicht erlaubt in dem href eines Links einen Parameter nur mit einem &-Zeichen dranzuhängen. Laut dem Standard muss es die entsprechende HTML-Entität sein, die so aussieht: & amp; PHP fügt leider nur ein & Zeichen hinzu und daher werden die Validatoren das als Fehler ankreiden, da sie keine Cookies annehmen. Bei dem Input-Feld, welches an Formulare drangehangen wird ist im Prinzip alles korrekt, jedoch nur dann wenn man XHTML als Standard definiert hat. Fährt man noch mit dem normalen HTML-Standard (deklariert wird das übrigens über den DocType) ist das /> am Ende des Inputfeldes syntaktisch falsch und wird auch als Fehler markiert. Die Lösung Eigentlich ganz einfach: Wir müssen PHP sagen, wie er diese automatischen Ergänzungen im Falle der Verwendung von Sessions ohne Cookies, ausgeben soll. Leichter gesagt als getan, denn das wird in der php.ini Datei vom Webserver gesteuert und nur die wenigsten haben darauf uneingeschränkten Zugriff. Unterstützt der Webserver aber .htaccess Dateien kann man manche Variablen aus der php.ini Datei verändern. So auch die für die Ergänzung relevanten. Einfach folgendes ganz oben in die .htaccess Datei schreiben, die sich im Root der Website befindet: php_value arg_separator.output & amp; Die erste Zeile macht aus dem falschen & in der URL ein & amp; (ohne Leerzeichen) und die zweite Zeile aus einem /> ein >. In der ersten Zeile muss das Leerzeichen zwischen & und amp; entfernt werden. Hier wandelt das CMS aber ein & amp; in der Ausgabe in ein & um. Daher dieser Umweg. Das Problem fällt einem erst dann auf, wenn man die Website über einen Online-Validator wie der vom W3C testet oder lokal die Cookies deaktiviert und auch nur dann, wenn man Sessions in PHP nutzt. Link Kommentare (4) |
||
Letzte Aktualisierung ( Montag, 30. März 2009 ) |
< Zurück | Weiter > |
---|