Session

Kurz: Ein zusammenhängender Kommunikationszeitraum zwischen zwei Parteien, in dem Zustand (z. B. Anmeldestatus) über mehrere einzelne Anfragen hinweg erhalten bleibt.

Genauer: Da viele Protokolle wie HTTP von sich aus zustandslos sind (jede Anfrage steht für sich), braucht es einen Mechanismus, um z. B. einen eingeloggten Nutzer über mehrere Seitenaufrufe hinweg wiederzuerkennen — meist über ein Session-Cookie, das eine eindeutige Session-ID enthält, während die eigentlichen Daten serverseitig gespeichert sind.

Im Detail

“Zustandslos” bei HTTP bedeutet: Der Server behandelt jeden Request komplett unabhängig von allen vorherigen — er “erinnert sich” von sich aus an nichts. Für viele Anwendungsfälle (eine eingeloggte Einkaufssitzung, ein Formular über mehrere Schritte) ist das unpraktisch, deshalb wurde das Session-Konzept obendrauf gebaut: Beim ersten Kontakt bekommt der Client eine eindeutige, zufällige Session-ID zugewiesen, die er bei jedem weiteren Request automatisch mitschickt (meist über ein Cookie). Der Server hält die eigentlichen Sitzungsdaten (z. B. “Nutzer 123 ist eingeloggt”) in einem serverseitigen Speicher (Datenbank, Redis-Cache o. ä.) und ordnet sie anhand der Session-ID zu.

Ein wichtiger Sicherheitsaspekt: Session-IDs müssen ausreichend zufällig und lang sein, damit sie nicht erraten werden können (“Session Hijacking” wäre sonst möglich), und sollten über eine sichere, verschlüsselte Verbindung (HTTPS) übertragen werden, damit sie nicht auf dem Übertragungsweg mitgelesen werden können. Session-Cookies bekommen dafür üblicherweise die Flags HttpOnly (nicht per JavaScript auslesbar) und Secure (nur über HTTPS gesendet).

Siehe auch: Cookies, Authentifizierung