Sessions mit JSON-Token – The stateless way
JSON-Token sind eine völlig andere Art mit Sessions umzugehen. Hier werden alle Daten in ein einzelnes Token codiert und mit einem Hash signiert. Das vollständige Token wird dann als Parameter in allen Requests mitgeschickt – ähnlich der Session-ID.
Ihr müsst hierbei allerdings beachten, dass die Daten nur signiert und nicht verschlüsselt sind. Das Token sieht zwar kryptisch aus, aber es ist nur base64 codiert. Ein einfacher Konverter zeigt also die tatsächlichen Daten. Die Daten werden auch nicht komprimiert, so dass ihr euch etwas zurück halten solltet was die Menge angeht. Perfekt wäre zum Beispiel eine User-ID, des eingeloggten Benutzers und das Erstellungsdatum des Tokens, damit ihr die Session auch irgendwann auslaufen lassen könnt.
Eine „Remember me“-Funktion bekommt ihr damit geschenkt. Der Benutzer benötigt nur das Token.
Keine Daten auf dem Server bedeutet auch, dass ihr keine Garbage Collection habt. Memcache löscht alte Einträge irgendwann und extrem viele Dateien auf der Festplatte werden schnell unhandlich.
Die Performance ist unschlagbar. Das bisschen base64_decode() und ein HMAC256 fallen praktisch nicht ins Gewicht. Alleine die Netzwerkabfrage der anderen Methoden dauert länger.
Das größte Problem an diesen Token ist der Logout. Hier liegt sehr viel im Verantwortungsbereich des Nutzers, die Token sind z. B. im Browserverlauf klar sichtbar. Wer das Token hat, hat die Session, ihr könnt die Daten nicht auf dem PC eurer Nutzer löschen.
Wenn ihr also einen Online-Shop betreibt, solltet ihr eure Benutzer-Session nicht über JSON-Tokens realisieren. Der Inhalt des Warenkorbs auf der anderen Seite wäre die perfekte Gelegenheit.
Vorteile von JSON-Tokens
- Keinerlei Daten auf den Servern
- Sessions können beliebig lange gültig bleiben
- Performance
Nachteile einer Session als reines JSON-Token
- Daten sind lesbar und damit möglicherweise nicht Datenschutz konform
- Korrekter Logout ist nicht ganz einfach