Wir müssen uns heute in PHP glücklicherweise kaum noch mit Session-Verwaltung beschäftigen, da praktisch alle Frameworks dies auf die ein oder andere Art abstrahieren und in eine hübsche API verpacken.
In diesem Artikel soll es trotzdem um die Grundlagen und Möglichkeiten einer eigenen Session-Verwaltung gehen. Gerade JSON-Tokens bieten eine schöne Möglichkeit Sessions zu realisieren ohne tatsächlich Daten auf dem Server zu speichern.
Inhalt
- Sessions Datei basiert – The old fashioned way
- Sessions in der Datenbank – The dirty way
- Sessions mit Memcache – The fast way
- Sessions mit JSON-Token – The stateless way
- Was sollte in einer Session gespeichert werden?
- Sicherheit
Sessions Datei basiert – The old fashioned way
Die Standard Installation von PHP bietet bereits eine vollständige Session-Verwaltung mit Dateien auf dem Server (ungefähr hier: /var/lib/php/sess). Alles was ihr tun müsst ist session_start(); und schon geht es los. Danach steht euch mit $_SESSION eine globale Variable (wie $_GET) zur Verfügung.
Alles was ihr in $_SESSION speichert wird von PHP, nachdem euer Skript beendet ist, in einer Datei auf der Festplatte gespeichert. Der Benutzer erhält ein Cookie (Name: PHPSESSID) mit seiner Session-ID (= Dateiname) und der von euch in der php.ini konfigurierten Laufzeit.
Wollt ihr keine Cookies auf eurer Seite, könnt ihr die Session-ID auch als Get-Parameter an die URL hängen. Dabei enthält die Konstante SID sowohl den Parameternamen als auch den Wert.
|
1 |
$url = 'www.example.com?'.SID; |
Das ist alles. Natürlich könnt ihr noch beliebige andere Parameter ergänzen. Wie der Parameter heißt, wird wieder in der php.ini definiert.
Die Daten werden vor dem Speichern mittels serialize() in einen String verwandelt und beim nächsten Session-Start per unserialze() in die Ursprungsform zurück geführt. Solltet ihr also nicht mit skalaren Daten, sondern Objekten arbeiten, empfiehlt es sich das Serializable Interface zu implementieren und die Daten selbst zu steuern. Zur Not geht das auch mit den magischen Methoden __sleep() und __wakeup().
Ein großes Problem Datei basierter Sessions liegt in der Natur der Sache: Die Datei liegt nur auf einer Festplatte. Bei Webclustern mit mehr als einem Server müsst ihr also irgendwie sicher stellen, dass der Benutzer wieder zu seiner Session findet. Das ließe sich zwar lösen, führt dann aber den Sinn eines Webclusters ad absurdum.
Denkbar wäre die Daten auf einem shared mount abzulegen, so dass alle Server auf die selben Dateien zugreifen können, oder alternativ dem Benutzer für die Laufzeit einer Session immer den selben Server zuzuweisen. Beides sind keine guten Lösungen, ihr solltet hier auf eine andere Speicherart ausweichen.
Vorteile der Datei basierten Variante
- Einfach und „frei Haus“ eingerichtet
- Kein Overhead durch zusätzliche Funktionen oder Netzwerkabfragen
Nachteile der Session in Dateien
- Die Session-Datei ist nur auf einem Webserver (Stichwort: Clusterbetrieb)
- Performance von Festplattenzugriffen ist schlecht im Vergleich zu anderen Möglichkeiten
Weiter mit Sessions in der Datenbank