Kapitel 13 · Security

Spring Session für clusterfähige Sessions

Typ: FrameworkVersion 2 ausführlich

Spring Session ersetzt containergebundene HTTP Sessions durch externe Repositorys wie Redis oder JDBC und macht Sessions clusterfähig.

‹ Zurück ⌂ Index Weiter ›

Fachliche Einordnung

Klassische Sticky Sessions und Application-Server-Replikation sind in Kubernetes und horizontal skalierenden Plattformen oft hinderlich.

Enterprise-Merksatz: Spring Session ersetzt containergebundene HTTP Sessions durch externe Repositorys wie Redis oder JDBC und macht Sessions clusterfähig.

Technische Darstellung

Kernkonzepte

HttpSession neutral ersetzen.
Redis oder JDBC als SessionRepository.
Header-basierte Session IDs für bestimmte API-Szenarien.
WebSocket Session Integration.
TTL, Logout und Session Fixation im Zusammenspiel mit Security.

Wann einsetzen?

Du betreibst stateful Web UIs auf mehreren Pods.
Du migrierst von WebSphere Session Replication.
Du willst Sessions unabhängig vom Servlet Container speichern.

Typische Fehler und Risiken

Session als Fachdatenspeicher missbrauchen.
Zu große Objekte serialisieren.
TTL und Logout nicht mit Security abstimmen.

Legacy- und Modernisierungssicht

Application-Server-Session-Replikation wird durch Redis/JDBC Session Repository ersetzt; Anwendungen werden containerneutraler und Cloud-tauglicher.

Ausführliches Beispiel

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

spring:
  session:
    store-type: redis
    timeout: 30m
  data:
    redis:
      host: redis.internal
      port: 6379
server:
  servlet:
    session:
      cookie:
        same-site: lax
        http-only: true
        secure: true

Checkliste für Reviews

Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?