Die Möglichkeit, Benutzerdaten über mehrere Webseiten hinweg zu erhalten und dem Benutzer wieder zuzuordnen, eröffnet neue Möglichkeiten für Webprogrammiererer. Administrative Webbereiche, wie z.B. Foren- oder Communityverwaltung, Benutzerverfolgung (User-Tracking), seitenübergreifende Formulare oder individuelle Inhalte für jeden einzelnen Benutzer (Customizing) werden mit Sessions möglich. Die Grundlagen der Sessionverwaltung mit PHP werden hier erläutert.
Wozu Sessions?
Sofern man dieses Tutorial online liest, wird man entweder auf einen Link geklickt, oder die Adresse dieser Seite manuell eingegeben haben. Spätestens dabei wird es (hoffentlich) aufgefallen sein, dass die Adressen der meisten Webseiten mit http:// beginnen.
Die Abkürzung HTTP liest sich “HyperText Transfer Protocol” und ist der Grundstein für das World Wide Web, wie wir es heute kennen – es regelt die Verständigung zwischen dem Client (z.B. Browser) und dem Webserver, der die auf ihm gespeicherten Webseiten zur Verfügung stellt.
In der derzeitigen Implementation (HTTP 1.1), hat das HTT-Protokoll leider einen großen Nachteil: es ist “zustandslos”. Vereinfacht bedeutet das:
- Der Client (Browser) öffnet eine Verbindung zum Webserver, und fragt nach einer Webseite (Request).
- Der Webserver antwortet (Response) mit dem gewünschten Inhalt (oder einer Fehlermeldung).
- Der Client empfängt bestenfalls die Daten und stellt sie dar.
- Die Verbindung zwischen Client und Server wird beendet, es wird kein “Zustand” – keine dauerhafte Verbindung – aufrecht erhalten.
Merke:
- Das HTT-Protokol ist zustandslos (stateless)
- Request: die Anfrage des Browsers an den Webserver
- Response: die Antwort des Webservers auf einen Request
Zunächst klingt diese Verfahrensweise logisch und nicht besonders tragisch, da offensichtlich die angeforderten Daten – wie gewünscht – ihren Weg zum Browser finden. Das Problem für den Programmierer der Webseiten-Logik entsteht erst dann, wenn es nötig wird, den Client von einem Request zum anderem zu identifizieren – d.h. die Requests zu unterscheiden, ob sie vom gleichem Client stammen oder nicht.
Diese Unterscheidung (Authentifizierung) ist schon z.B. bei einer einfachen Warenkorb-Funktion notwendig, damit bestellte Artikel nicht im Warenkorb eines anderen Benutzers landen, der sich zufällig zur gleichen Zeit im gleichem Online-Shop bewegt. Ebenfalls wird diese Unterscheidung notwendig, um ausgewählten Benutzern restriktiven Zugriff auf spezielle Teile einer Website zu erlauben (Authorisierung) z.B. auf Administrationsbereiche oder Bereiche in denen Informationen für einen geschlossenen Benutzerkreis (CUG – closed user group) zur Verfügung stehen.
Eine eindeutige Unterscheidung anhand der IP-Adresse ist – wie es oft landläufig von Neulingen geglaubt wird – nicht möglich bzw. stellt aus der Sicht des Webservers keinen sicheren Weg zu Authentifizierung eines Clients dar, da einerseits mehrere Clients mit der gleichen IP im WWW unterwegs sein können (Masquerading) und andereseits ein Client über mehrere Requests hinweg verschiedene IP-Adressen (Proxies) haben kann. Wie das genau funktioniert ist aber eine andere Geschichte.
Merke:
- Eine IP ist in unserem Kontext nicht eindeutig.
- Authentifizierung: Wiedererkennung eines Benutzers.
- Authorisierung: Überprüfung individueller Zugangsdaten eines wiedererkannten Benutzers und Gewährleistung damit vebundener Rechte.
Die Lösung für das Problem sind sog. Sessions-IDs, eindeutige “Schlüssel”, die bei der HTTP-Kommunkation über den Zeitraum einer Sitzung (engl. Session) auf einer Webseite ihre Gültigkeiten behalten.
Was ist eine Session-ID? Wo werden Sessiondaten gespeichert?
Die Session-ID – es ist eine zufällige Zeichenfolge – wird serverseitig generiert und wird beim allerersten Response des Webservers an den Browser geschickt, der sie dann speichert. Üblicherweise wird eine Session-ID in Cookies abgelegt, da der Browser bei jedem Request automatisch den Inhalt des Cookies an den Webserver schickt der ihn gesetzt hat.
Dies bedeutet, dass sich der Programmierer der serverseitigen Software theoretisch keine Sorgen machen muss, wie die Session-ID vom Browser wieder zurück zum Webserver kommt, da diese Arbeit automatisch vom Browser erledigt wird.
Cookies sind nichts anderes als menschenlesbare Textdateien, in denen ein Webserver spezifische Daten auf der lokalen Platte des Benutzers ablegen kann. Diese Daten sind u.U. recht kryptisch gehalten, so daß meistens nur der Autor der serverseitigen Software – die den Cookie gesetzt hat – weiß, wie diese Cookie-Daten zu interpretieren sind.
Dies ist aber für uns irrelevant und soll uns nicht weiter beschäftigen, denn wir wollen feststellen, daß die Größe des Cookie – per Definition – ca. 4000 Zeichen nicht überschreiten darf (wovon wir ca. 40 Zeichen benötigen), und dass es zwei Arten von Cookies gibt:
- “Persistente Cookies” werden für einen definierten Zeitraum (Gültigkeitsdauer) auf der Festplatte des Benutzers als normal lesbare Textdatei gespeichert. Dieser Zeitraum kann sich von wenigen Minuten bis mehreren Jahren erstrecken.
- Die Lebensdauer der “temporären Session-Cookies” beschränkt sich auf die Lebensdauer des Browser-Fensters. Wird dieses geschlossen, wird auch der temporäre Cookie verworfen. Dieser Cookie wird üblicherweise nicht auf der Festplatte gespeichert; er residiert im Arbeitsspeicher des Rechners.
In der Standardeinstellung benutzt PHP 4 die zweite Variante – die temporären Cookies – um Session-IDs zu speichern. Im Cookie wird der Name der Session und die bereits erwähnte zufällige Zeichenfolge der Session-ID gespeichert. Der Name der Session ist eine frei wählbare Bezeichnung, die uns später als Variable bei der Auswertung der Sessiondaten im PHP-Script zu Verfügung stehen wird. Per Voreinstellung lautet der Name der Variable bei PHP 4: PHPSESSID. Die Länge der von PHP 4 produzierten Session-ID beträgt 32 Zeichen.
Als Ergebnis können wir annehmen, dass bei der Initialisierung einer Session, PHP einen Cookie mit etwa dem folgenden Inhalt beim Benutzer hinterlegt:
PHPSESSID=edb0e8665db4e9042fe0176a89aade16
Der linke Teil des Strings wird als Sessionname und der rechte – die zufällige Zeichenkette “edb0e8665db4e9042fe0176a89aade16″ – als Session-ID bezeichnet.
Diese Session-ID ist der Schlüssel zur Wiedererkennung des Benutzers und zur Restaurierung der von ihm gesetzten Daten. Die Session-ID repräsentiert bei PHP 4 – per Voreinstellung – eine temporäre Datei im Filesystem des Servers. Auf unixoiden Betriebssystemen wird die PHP-Sessiondatei standardmäßig im Verzeichnis /tmp/ erstellt. In der php.ini – der globalen Konfigurationsdatei – oder ein der Webserverkonfiguration läßt sich dieser Wert natürlich verändern.
Diese Session-Datei bekommt im Namen den Prefix sess_, so dass das Ergebnis im Filesystem des Servers folgendermaßen aussehen kann:
goosh@warpcore:~> ls /tmp/ -l insgesamt 0 -rw------- 1 wwwrun www 0 Apr 17 18:00 sess_edb0e8665db4...
In dieser Datei kann ein PHP-Script Benutzerdaten ablegen – z.B. die Artikelnummer und die Anzahl der bestellten Artikel für einen Warenkorb oder einfach nur ob ein Benutzer sich authorisiert hat und Zugriff auf eine Webseite hat.
Dadurch dass der Browser den Inhalt des Cookies bei einem Request mitschickt, ist es möglich den Benutzer über mehrere Webseiten zu authentifizieren oder die vom Benutzer gesetzten Variablen von einer Seite auf eine andere zu übernehmen.
Die Manipulation dieser Session-Datei bleibt nur dem serverseitig ausgeführtem PHP-Script vorbehalten. Der Client weiß nicht welche Daten von dem Script gespeichert werden und er kann keinen mittelbaren Einfluß auf diese Daten nehmen. Ausnahme bildet hier die Änderung oder Löschung dieser Daten durch den Administrator oder durch ein auf dem Server laufendes Script mit entsprechenden (Datei-)Rechten.
Merke:
- In der Voreinstellung benutzt PHP 4 temporäre Cookies um Session-IDs zu speichern.
- Defaultname der Session ist PHPSESSID.
- Eine mit PHP 4 generierte Session-ID ist 32 Zeichen lang (MD5 digest).
- Sessiondateien werden im Ordner /tmp/ gespeichert.
- Sessiondateien können nur serverseitig geändert werden.
