Sitzungsmodell: Komfort und Einschränkungen

1. Bewertung des Sitzungsmodells

Jetzt, da wir den gesamten Zyklus von login -> Reihe von Anfragen -> logout -> timeout gesehen haben, können wir aufhören, die Sitzung nur als „Mechanik unter der Haube“ zu betrachten und sie als technische Lösung zu bewerten. Gerade am Lebenszyklus wird am besten deutlich, wo das session-basierte Modell praktisch ist und wo man dafür bezahlen muss.

Wenn Sie gerade erst anfangen, ist es sehr leicht, in eines der beiden Extreme zu verfallen. Das erste – „Die Sitzung ist Magie, ich fasse sie nicht an“. Das zweite – „Die Sitzung ist von gestern, lasst uns ohne sie arbeiten“. Beide Extreme enden meistens gleich: unerwartete 401/403, kaputte Szenarien und das Gefühl, dass Spring Security ein Eigenleben führt.

Das Sitzungsmodell ist weder Magie noch ein Relikt der Vergangenheit. Es ist eine Möglichkeit, den authentifizierten Zustand auf dem Server zu halten und zwischen zusammenhängenden Anfragen wiederherzustellen. Solange der Browser die Session-ID mitschickt, kann der Server dem Benutzer seinen SecurityContext zurückgeben, ohne dass dieser sich erneut anmelden muss.

Genau daraus entstehen sowohl die Vorteile als auch der Preis des Modells: praktische Kontinuität für den Browser, aber gleichzeitig Speicher auf dem Server, Timeouts, Logout-Semantik und Skalierungsfragen. Im Folgenden schauen wir uns an, wo dieses Modell natürlich ist und wo es anfängt zu stören.

2. Wo die Sitzung praktisch ist

Das Sitzungsmodell ist dort praktisch, wo der Benutzer viele zusammenhängende Anfragen stellt und erwartet, dass das System seinen Zustand zwischen diesen Anfragen „behält“. Das anschaulichste Beispiel ist das Browserszenario: Der Benutzer öffnet die Anwendung, meldet sich an und bewegt sich dann in seinem persönlichen Bereich. Er muss nicht jedes Mal aufs Neue beweisen, wer er ist. In Ihrem Gehirn fühlt sich das an wie „ich bin schon eingeloggt“, und auf der Serverseite fühlt es sich an wie „ich habe eine Session-ID, unter der ich den gespeicherten SecurityContext finde“.

Im übertragenen Sinne ist das wie ein Armband im Freibad: Die Eintrittskarte wurde einmal geprüft, und von da an erkennt das System Sie an der ausgegebenen Kennung. JSESSIONID ist in dieser Analogie die Kennung; HttpSession ist der Server-Eintrag; SecurityContext ist der Vermerk, dass Sie bereits authentifiziert sind und welche Rechte Sie haben.

In unserem Übungsprojekt Secure Content Platform API wird dieser Komfort besonders im persönlichen Bereich deutlich. Der Benutzer meldet sich an – und kann dann beruhigt eine Reihe von Aufrufen tätigen:

GET /api/me – „Wer bin ich?“

GET /api/me/profile – „Mein Profil“

GET /api/drafts – „Meine Entwürfe“

In all diesen Anfragen „erinnern“ sich die Controller nicht an den vorherigen Aufruf. Sie erhalten den bereits wiederhergestellten Authentication/Principal im Rahmen der aktuellen Anfrage, weil Spring Security den SecurityContext aus der Sitzung wiederhergestellt hat. Für den Entwickler fühlt sich das wie ein sehr angenehmes Modell an: Der Geschäftscode muss sich nicht bei jedem Schritt um die erneute Authentifizierung kümmern.

Hier ist ein einfaches Beispiel eines Controllers, der den Komfort der Sitzung nutzt: Der aktuelle Benutzer ist ohne großen Aufwand für die Anmeldung bei jeder Anfrage verfügbar.

package com.example.securecontent.me;

import java.security.Principal;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
class MeController {

    // Spring Security hat den SecurityContext bereits aus der Sitzung wiederhergestellt,
    // daher ist Principal direkt in den Methodenparametern verfügbar.
    @GetMapping("/api/me")
    String me(Principal principal) {
        // In einer realen Anwendung ist dieser Endpoint normalerweise geschützt,
        // daher wird principal hier als nicht null erwartet.
        return "Hello, " + principal.getName(); // Hello, alice
    }
}

Beachten Sie: In dieser Methode gibt es weder ein Passwort noch ein Login-Formular noch ein explizites Lesen von Cookies. Und das liegt nicht daran, dass „Spring alles versteckt hat“, sondern weil Sie die Mechanik bereits verstehen: Die Sitzung ist mit JSESSIONID verknüpft, Spring Security hat den Kontext wiederhergestellt, und hier ist er – der Principal. Das ist die Stärke des session-basierten Modells: Es macht den „persönlichen Bereich“ natürlich.

Ein weiterer Vorteil ist die Steuerbarkeit von der Serverseite. Der Server kann den authentifizierten Zustand durch Logout oder Timeout beenden, und der Benutzer wird wieder anonym. Das ist nicht immer „angenehm für den Benutzer“, aber es ist steuerbar. Und Steuerbarkeit ist ein wichtiger Teil von Sicherheit und Betrieb, selbst wenn Sie gerade ein Übungsprojekt schreiben.

3. Der Preis: Der Zustand wird auf dem Server gespeichert

Wenn Sie den Zustand auf dem Server speichern, sagen Sie im Grunde: „Für jeden aktiven Kunden habe ich irgendwo auf dem Server ein Stück Speicher (und Metadaten), das ich verwalten muss.“ Und hier beginnen die Einschränkungen, die man gerne ignorieren möchte, die sich aber nicht ignorieren lassen.

Die erste Einschränkung sind Speicher und Ressourcen. Eine Sitzung muss nicht riesig sein, aber ihre Existenz bedeutet, dass der Server irgendwo eine Struktur „Session-ID – Sitzungsdaten“ vorhalten muss. Selbst wenn Sie nichts explizit in die Sitzung legen, legt Spring Security dort den SecurityContext ab. In einem kleinen Übungsprojekt ist das nicht schlimm, aber in einer realen Anwendung wird „viele aktive Benutzer“ zu „vielen aktiven Sitzungen“. Und viele aktive Sitzungen sind dann keine Philosophie mehr, sondern konkrete Zahlen zu Speicher und Last.

Die zweite Einschränkung: Die Lebensdauer der Sitzung wird zum Teil des Systemverhaltens. Wenn die Sitzung zu lang ist, bleibt der Benutzer „lange eingeloggt“, selbst wenn er vergessen hat, seinen Laptop im Café zu schließen (rein hypothetisch natürlich). Wenn die Sitzung zu kurz ist, wird der Benutzer ständig „rausgeworfen“ und ärgert sich. Und das ist nicht nur UX – das ist auch Support: „Warum werde ich alle 2 Minuten ausgeloggt?“ wird schnell zu Ihrer Lieblingsaufgabe der Woche.

In Spring Boot kann das Sitzungs-Timeout in der Konfiguration eingestellt werden. Für ein Übungsprojekt ist das eine hervorragende Möglichkeit, bewusst zu sehen, dass die Sitzung „nicht ewig“ ist, sondern nach Regeln lebt.

# application.yml
server:
  servlet:
    session:
      # Inaktivitäts-Timeout: Wenn N Minuten lang keine Anfragen mit dieser Sitzung eingehen, läuft sie ab.
      timeout: 15m

Hier ist nicht so sehr der Wert wichtig, sondern der Gedanke: Das Timeout ist keine „magische Einstellung irgendwo unten“. Es ist Teil des Modells Ihrer Anwendung. Und wenn Sie es nicht kontrollieren, wird es Sie kontrollieren.

Die dritte Einschränkung sind mehrere Instanzen der Anwendung. Selbst wenn Sie noch nichts „auf mehrere Instanzen“ deployed haben, ist es hilfreich, das Problem konzeptionell zu verstehen. Stellen Sie sich vor, Ihre Anwendung läuft in zwei Kopien: app-1 und app-2. Der Benutzer meldet sich bei app-1 an, erhält JSESSIONID, und die nächste Anfrage landet zufällig bei app-2. Wenn app-2 nichts von dieser Sitzung weiß, kann es den SecurityContext nicht wiederherstellen, und der Benutzer wird plötzlich anonym. „Aber ich bin doch gerade erst eingeloggt!“ – wird der Benutzer sagen. „Und ich sehe Sie zum ersten Mal“ – wird app-2 sagen. Und beide haben auf ihre Weise recht.

Man kann sich das so vorstellen:

sequenceDiagram
    %% Problem: Die Sitzung lebt auf einer bestimmten Instanz und eine andere Instanz weiß nichts von ihr.
    participant B as Browser
    participant A1 as "App instance #1"
    participant A2 as "App instance #2"

    B->>A1: "POST /login (erfolgreich)"
    A1-->>B: Set-Cookie: JSESSIONID=abc

    B->>A2: "GET /api/me (Cookie: abc)"
    A2-->>B: "401 (kennt Sitzung abc nicht)"

Wir werden heute nicht darauf eingehen, wie genau das in der Infrastruktur gelöst wird (das ist ein eigenes großes Thema). Aber es ist wichtig, die Grenze zu sehen: Das session-basierte Modell funktioniert natürlich in einer „Ein-Server/Eine-Kopie“-Welt, und bei der Skalierung müssen Sie sich zwangsläufig Gedanken darüber machen, wie Anfragen zur richtigen Instanz gelangen und wo die Sitzungen leben.

Die vierte Einschränkung: Die Sitzung als „Müllhalde“ für Daten. Sehr oft sehen Anfänger die HttpSession als praktische Tasche: „Oh, da kann ich alles reinstecken!“ Technisch gesehen geht das. Die Methode setAttribute verbietet es Ihnen nicht. Aber architektonisch ist das fast immer eine schlechte Idee, weil Sie die Sitzung in ein verstecktes Speichermedium für Geschäftsdaten verwandeln, die:

• schwer zu testen sind (sie sind „irgendwo da“);
• schwer zu verstehen sind (warum sind sie plötzlich da oder nicht da);
• schwer zu warten sind (Timeout und Invalidierung beginnen, Geschäftsszenarien zu zerstören).

In Übungsbeispielen ist ein „Besuchszähler“ in Ordnung – er zeigt die Mechanik. In einer realen Anwendung „das Benutzerprofil, die Liste der Entwürfe und den aktuellen Entwurf in die Sitzung zu stopfen, weil das schneller ist“ – das ist so gut wie garantierter Schmerz.

Um den Unterschied besser zu spüren, schauen wir uns zwei Fragmente an: ein schlechtes und ein gutes (das gute ist nicht immer kürzer, aber es ist ehrlicher).

Eine schlechte Angewohnheit ist es, in der Sitzung „ein Stück Domäne“ zu speichern, als ob es ein Cache wäre:

package com.example.securecontent.badidea;

import com.example.securecontent.profile.UserProfileDto;
import jakarta.servlet.http.HttpSession;

class SessionStuffingExample {

    void dontDoThis(HttpSession session, UserProfileDto profile) {
        // Es ist verlockend, das zu tun, aber es bindet die Geschäftslogik an den Lebenszyklus der Sitzung.
        // Timeout/Logout/Neustart der Anwendung können diese Daten leicht 'löschen'.
        session.setAttribute("profile", profile); // 'bequem', aber sehr zerbrechlich
    }
}

Ja, es funktioniert. Aber dann fügen Sie Logout, Timeout, eine zweite Anwendungsinstanz hinzu oder ändern einfach das DTO – und plötzlich beginnt die „Magie des Datenverschwindens“. Die Sitzung ist gut als Mechanismus zur Aufrechterhaltung des Sicherheitskontexts, aber als Speicher für Geschäftsdaten wird sie fast immer zu einer „Blackbox“.

Der fünfte Preis: Statefulness beeinflusst die Diagnose. In einer zustandslosen Welt (wir diskutieren sie heute nicht, nur als Gedanke) ist jede Anfrage in sich abgeschlossen. In der session-basierten Welt kann eine Anfrage „mit Kontext“ oder „ohne Kontext“ sein, und das beeinflusst das Ergebnis. Daher muss man sich beim Debuggen die Frage stellen können: „Ist diese Anfrage überhaupt mit der richtigen Sitzung gekommen?“

4. Steuerbarkeit: Die Sitzung unter Kontrolle

Nach dem vorherigen Abschnitt könnte man leicht zu dem falschen Schluss kommen: „Na gut, die Sitzung ist nur ein Problem.“ Das ist nicht so. Tatsächlich entstehen Probleme nicht aus der Existenz der Sitzung, sondern daraus, dass wir sie wie unkontrollierte Magie behandeln. Deshalb halten wir hier ein paar praktische Prinzipien fest, die das session-basierte Modell vorhersehbar und ruhig machen.

Das erste Prinzip: Die Sitzung sollte „dünn“ sein. In einer idealen Welt speichern Sie darin nur das, was wirklich zur Aufrechterhaltung des Authentifizierungszustands benötigt wird (und einen minimalen technischen Kontext). Alles andere – Geschäftsdaten – lebt in Ihrem normalen Anwendungsmodell: in der Datenbank, in Diensten, in DTOs pro Anfrage. Je weniger Sie „Ihr Eigenes“ in die Sitzung legen, desto weniger Überraschungen gibt es durch Timeout, Logout und andere Lebensereignisse.

Das zweite Prinzip: Logout sollte explizit sein und den Zustand auf dem Server beenden, nicht nur darauf hoffen, dass das Cookie verschwindet. Sie haben bereits gesehen, dass man das Verhalten des Logouts steuern kann, und im Projekt hilft das, das Verhalten „ehrlich“ zu machen: Der Benutzer hat sich abgemeldet – die Sitzung ist ungültig, das Cookie ist gelöscht.

Beispiel einer Konfiguration (wir haben etwas Ähnliches in der vorherigen Vorlesung gemacht, aber hier geht es um den Gedanken der „Steuerbarkeit“):

package com.example.securecontent.security.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;

@Configuration
class SecurityConfig {

    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            // Konfigurieren der Autorisierung auf HTTP-Anfrageebene.
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**", "/debug/**").permitAll() // Öffentliche Endpunkte und Debug-Bereich
                .anyRequest().authenticated() // Alles andere erfordert Authentifizierung (d.h. Sitzung)
            )
            // formLogin aktivieren: Nach erfolgreichem Login erstellt/nutzt Spring eine Sitzung und legt dort den SecurityContext ab.
            .formLogin(Customizer.withDefaults())
            // Logout muss den Serverzustand ungültig machen, nicht nur "den Browser bitten, das Cookie zu vergessen".
            .logout(logout -> logout
                .invalidateHttpSession(true) // HttpSession auf dem Server zerstören
                .deleteCookies("JSESSIONID") // Session-ID beim Client löschen
            );

        return http.build();
    }
}

Das dritte Prinzip: Das Timeout sollte sinnvoll sein. Selbst in einem Übungsprojekt ist es nützlich, einen klaren Wert zu setzen und mit eigenen Augen zu sehen, dass der Benutzer nach „N Minuten Inaktivität“ wieder anonym wird. Das gibt Ihnen ein echtes Verständnis dafür, warum der Benutzer manchmal „verschwunden“ ist: nicht, weil der Controller ihn „vergessen“ hat, sondern weil die Sitzung verschwunden ist – und damit die Quelle, aus der der SecurityContext wiederhergestellt wurde.

Das vierte Prinzip: Die Sitzung ersetzt nicht die Autorisierung. Das ist ein erstaunlich häufiger Denkfehler: „Wenn jemand eingeloggt ist, darf er alles.“ Nein, der Login ist nur die Tatsache der Authentifizierung. Die Zugriffsregeln (roles/authorities und die konfiguration auf Anfrageebene) bleiben verbindlich. Die Sitzung macht den Benutzer „erkannt“, aber nicht automatisch „allmächtig“.

Kurz gesagt: Die Sitzung beantwortet „Wer bist du?“, die Zugriffsregeln beantworten „Was darfst du?“. Und das sind unterschiedliche Fragen, auch wenn sie im Kopf eines Anfängers manchmal zu einem Brei verschmelzen.

5. Die Sitzung in unserem Projekt

Im Projekt Secure Content Platform API wird der Komfort des Sitzungsmodells deutlich, wenn Sie die persönlichen Endpunkte als ein zusammenhängendes Benutzerszenario betrachten, nicht als lose HTTP-Aufrufe. Der Benutzer hat sich im System angemeldet – und dann „lebt“ er im persönlichen Bereich. Er liest sein Profil, sieht sich Entwürfe an, bearbeitet Inhalte. Dabei müssen die Controller und Dienste nicht wissen, wie genau der Login erfolgt ist. Sie müssen lediglich den aktuellen Benutzer erhalten und die Zugriffsregeln anwenden.

Zum Beispiel kann der Endpunkt für die Liste der Entwürfe sehr einfach aussehen, weil bereits bekannt ist, „wer die Anfrage stellt“:

package com.example.securecontent.content;

import java.security.Principal;
import java.util.List;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
class DraftController {

    @GetMapping("/api/drafts")
    List<String> drafts(Principal principal) {
        // Principal stammt aus dem SecurityContext, den Spring Security aus der Sitzung holt.
        // Das heißt, wir übergeben nicht bei jeder Anfrage Login/Passwort – darin liegt der Komfort des stateful-Modells.
        return List.of("drafts of " + principal.getName()); // drafts of alice
    }
}

Ja, das ist nur ein Platzhalter. Aber er unterstreicht perfekt das Thema des heutigen Tages: In der session-basierten Variante entsteht das Gefühl eines „fortgesetzten Gesprächs“. Einmal eingeloggt – und überall sehen Sie denselben Benutzer, solange die Sitzung lebt.

Nun zu den Einschränkungen. Wenn Sie plötzlich einen „intelligenten Cache“ für Entwürfe in der Sitzung erstellen, um „unnötige Abfragen zu vermeiden“, werden Sie sich mit ziemlicher Sicherheit Probleme einhandeln. Warum? Weil:

- der Benutzer zwei Fenster öffnen, Änderungen vornehmen und eine Desynchronisation erleben kann;

- die Sitzung ablaufen kann und der „Cache“ verschwindet;

- Logout die Sitzung löscht und der Zustand unerwartet „verschwindet“;

- bei mehreren Anwendungsinstanzen erhalten Sie unterschiedliche Sitzungen (abhängig von der Routenführung der Anfragen).

Daher lautet die richtige Schlussfolgerung für das Übungsprojekt: Die Sitzung hilft, den Sicherheitszustand zu halten, aber sollte nicht zum Speicher für Domain-Daten werden.

Und noch ein wichtiger Gedanke speziell für unseren Kurs. Selbst wenn Sie das Gefühl haben, dass die Sitzung „das Zugriffsproblem löst“, löst sie es nur im ersten Schritt: Sie macht den Benutzer authentifiziert. Aber die Endpunkte /api/editor/** und /api/admin/** müssen trotzdem Rollen/Rechte prüfen. Und das ist gut so, denn sonst hätten wir ein „System: eingeloggt – und alles erlaubt“, und das wäre keine Content-Plattform, sondern ein Raum ohne Türen.

6. Wann die Sitzung stört

Das Sitzungsmodell beginnt zu stören, nicht weil es „schlecht“ ist, sondern weil sich die Anforderungen und die Umgebung ändern. Grob gesagt: Wenn Ihr Client ein Browser ist und der Benutzer eine Reihe zusammenhängender Aktionen ausführt, fühlt sich die Sitzung fast immer natürlich an. Wenn es viele verschiedene Clients gibt, die Anwendung oft horizontal skaliert wird oder eine strenge Vorhersagbarkeit jeder Anfrage unabhängig von der Historie wichtig ist – dann beginnt man den Preis des serverseitigen Zustands zu spüren.

In einem Übungsprojekt äußert sich das sanft: Sie können ein Timeout erleben, vergessen, dass ein Neustart der Anwendung die Sitzungen „tötet“, und sich wundern, warum Sie ausgeloggt wurden. Das sind nützliche „kleine Schmerzen“, die eine gute ingenieurtechnische Disziplin fördern: Sie beginnen zu verstehen, dass der Zustand auf dem Server lebt und einen Lebenszyklus hat.

In der realen Welt werden die Einschränkungen greifbarer. Sie möchten zwei Kopien der Anwendung laufen lassen (damit sie beim Neustart einer Kopie nicht vollständig ausfällt). Oder Sie möchten die Anwendung in einer Umgebung betreiben, in der Anfragen bei verschiedenen Instanzen landen können. Oder Sie möchten, dass die Clients nicht nur Browser, sondern auch etwas anderes sein können. Und dann beginnt „die Sitzung als einzige Möglichkeit, den Login zu halten“, zusätzliche Lösungen zu erfordern.

Aber – und das ist grundlegend – das macht die Sitzung nicht „schlecht“. Es macht sie zu einem Werkzeug mit einem Anwendungsbereich. Wie ein Hammer: ein hervorragendes Werkzeug, solange Sie Nägel einschlagen. Aber mit einem Hammer Schrauben einzudrehen – das liegt nicht am „Hammer, der veraltet ist“, sondern an der Tatsache, dass wir das falsche Werkzeug gewählt haben.

Daher lautet die ausgereifte Position auf Junior-/Junior+-Niveau: Die Sitzung ist ein normales Modell, insbesondere für browserorientierte Szenarien. Sie hat nur Einschränkungen, und genau an diesen Einschränkungen zeigt sich der Unterschied zu Modellen, bei denen der Client sich bei jeder Anfrage separat ausweist und der Server nicht dieselbe Kontinuität bei sich behält.

7. Typische Fehler im Umgang mit der Sitzung

Fehler Nr. 1: Das Sitzungsmodell als „grundsätzlich schlecht“ erklären.
Manchmal hört ein Neuling den Satz „session is outdated“ und beginnt, ihn als Naturgesetz zu betrachten. In der Folge versucht er, die Sitzung zu verwerfen, ohne zu verstehen, was genau sie an Komfort bot und welche Probleme sie löste. Viel nützlicher ist es, nicht ideologisch zu denken, sondern kontextbezogen: Wenn ein Benutzer viele zusammenhängende Aktionen aus einem einzelnen Browser-Thread ausführt, ist die Sitzung die natürliche Wahl, und das ist in Ordnung.

Fehler Nr. 2: Die Serverkosten und den Lebenszyklus der Sitzung ignorieren.
Solange das Projekt klein ist, scheinen Sitzungen „nichts zu kosten“. Aber dann tauchen plötzlich Timeout, Logout, Neustart der Anwendung auf, und der Benutzer „geht verloren“. Das ist kein Fehler von Spring Security und nicht „der Controller hat den Benutzer vergessen“ – das ist der normale Preis des serverseitigen Zustands. Eine nützliche Gewohnheit: Immer im Hinterkopf behalten, dass die Sitzung verschwinden kann und daher der SecurityContext möglicherweise nicht wiederhergestellt wird.

Fehler Nr. 3: Alles Mögliche in die HttpSession stecken und sie so zur Müllhalde machen.
session.setAttribute ist sehr verlockend: Profil, Entwürfe, aktueller Filter und alles Mögliche hineinlegen. Das Problem ist, dass die Sitzung dann aufhört, ein dünner Teil der Sicherheitsmechanik zu sein, und zu einem versteckten Speicher für Geschäftsdaten wird. Logout und Timeout beginnen dann, die Funktionalität zu zerstören, und der Code wird schwerer zu verstehen und zu testen. Der Sitzungszustand sollte kurz und vorhersagbar bleiben.

Fehler Nr. 4: Denken, dass „eingeloggt“ = „alles erlaubt“ bedeutet.
Die Sitzung liefert Ihnen einen authentifizierten Benutzer, ersetzt aber nicht die Autorisierung. Selbst wenn der Benutzer „erkannt“ ist, braucht er dennoch Zugriffsregeln: Einschränkungen auf Anfrageebene, Rollen, Berechtigungen. Sonst werden der persönliche Bereich, der Redaktionsbereich und der Adminbereich zu einem einzigen großen Gemeinschaftsraum. Das richtige mentale Modell: Die Sitzung hilft, die Frage „Wer bist du?“ zu beantworten, und die Zugriffsregeln beantworten „Was darfst du?“.

Fehler Nr. 5: Das Problem der Sitzung mit dem Problem des Cookies verwechseln.
Manchmal sieht ein Entwickler JSESSIONID und beginnt zu glauben, dass das Cookie die „Anmeldedaten“ des Benutzers seien. Dann behandelt er es wie ein Passwort: protokollieren, kopieren, manuell in Anfragen einfügen, im Team-Chat diskutieren. In Wirklichkeit ist das Cookie nur ein Identifikator für die Verbindung zwischen Client und serverseitiger Sitzung. Es ist wichtig, ja, aber es ist weder „Login“ noch „Rolle“. Und vor allem sollte man es weder anbeten noch fürchten: Es reicht zu verstehen, dass es der Schlüssel zum serverseitigen Zustand ist und sorgfältig behandelt werden muss.