17.14 Sitzungsverfolgung (Session Tracking) 

Im vorigen Kapitel haben wir uns mit dem Problem beschäftigt, wie trotz des zustandslosen Protokolls ein Verlauf auf dem Server verwaltet werden kann. Wir haben dafür die kleinen Informationseinheiten der Cookies eingesetzt, doch es gibt andere Lösungen, die wir noch einmal mit ihren Vor- und Nachteilen zusammenfassen:

Cookies Ein Cookie speichert eine Kennung, so dass der Server den Client erkennt und die Informationen für ihn speziell aufbereitet. Obwohl dies in Java durch die Cookie-Klasse einfach möglich ist, hat dieser Ansatz noch ein paar Schwächen. Es fällt dem Servlet die Aufgabe zu, aus der Cookie-Kennung die entsprechende Sitzung herauszusuchen und die Daten zu holen. Ein weiteres Problem ergibt sich dadurch, dass Cookies zwar möglich sind, aber vom Benutzer abgelehnt werden können, da dieser seine Anonymität aufs Spiel gesetzt sieht. Schaltet der Benutzer in seinem Lieblingsbrowser die Cookies aus, können wir nichts machen. Doch auch wenn Cookies verwendet werden, bleibt die Frage, wie lange der Cookie gültig sein soll. Hier ist zu überlegen, ob die normale Handhabung, dass der Keks nur eine Sitzung übersteht, sinnvoll ist.

URL-Rewriting Da ein Servlet vom Aufrufer Parameter bekommen kann, ist es eine nette Idee, an die URL einen Wert anzuhängen, der die aktuelle Sitzung kennzeichnet. Diese Kennung entspricht dann genau dem Wert des Cookies. Die Lösung ist simpel und funktioniert bei allen Browsern. Der Nachteil auf der Server-Seite ist wiederum, dass uns die Aufgabe zufällt, der Kennung die Sitzung zuzuordnen. Zudem ist Vorsicht geboten, da diese Kennung bei jedem Verweis wieder angehängt wird. Außerdem ist es für den Benutzer sehr unschön, diese Kennungen zu sehen, zumal sie in die Bookmarks übernommen werden. Dies führt zu dem Problem, dass eine Sitzung angesprochen werden kann, die gar nicht mehr existiert. Dies ist ein sehr schwer wiegendes Problem, da die Anhängsel ja nicht wie Cookies automatisch veralten.

Versteckte Felder (engl. hidden fields) In HTML-Seiten lassen sich versteckte Informationen in Formularen anlegen, die dann automatisch beim Versenden mitgeschickt werden. Dies sieht etwa so aus:

   <INPUT TYPE="HIDDEN" NAME="session" VALUE="...">

Cookies erlauben dem Server, den Client wieder zu erkennen und ihn einer Sitzung zuzuordnen. Doch wir haben gesehen, dass unser Servletcode noch einiges an Arbeit investieren muss. Der Cookie musste gesetzt und geholt werden, und wir mussten die Daten in einer Datenstruktur verwalten. Wenn der Benutzer Cookies ablehnt, müssen wir eine zweite Implementierung anbieten, die Sitzungsinformationen an die URL anhängt.

Glücklicherweise entlastet uns die Servlet-API und bietet die Klasse HttpSession an, eine Bibliothek auf hohem Niveau für die Verwaltung einer Sitzung. Sie basiert entweder auf Cookies oder URL-Rewriting, doch das wird von der API transparent gehalten. Als Programmierer bekommen wir so gut wie gar nichts davon mit. Mag der Client keine Kekse, so wandeln wir alle Informationen in URLs um, die wir dann anbieten. Ein Sitzungsobjekt verwaltet auch selbstständig in einer Datenstruktur die gesicherten Daten. Hier fällt für uns keine Arbeit an. Sitzungsobjekte können leicht verwendet werden, wie wir noch sehen werden. Sie können leider keine geschützten Felder nutzen.

17.14.1 Das mit einer Sitzung verbundene Objekt HttpSession 

Jede Sitzung ist mit einem Sitzungsobjekt verbunden, welches die Klasse HttpSession abbildet. Bei JSPs repräsentiert das implizite Objekt session die aktuelle Sitzung.

17.14.2 Werte mit einer Sitzung assoziieren und auslesen 

Um Informationen mit der Sitzung zu verbinden, verwenden wir die Methode setAttribute(), die einen Schlüssel und einen Wert verbindet. Daten werden mit getAttribute() wieder aus der Datenstruktur gelockt, so wie es folgendes Beispiel zeigt:

List l = (List) session.getAttribute( "artikel" );

Hier verbinden wir mit einem Schlüssel eine Liste von Waren. Im Hintergrund werden die Informationen auf der Server-Seite gesichert. Die Informationen selbst werden nicht in Cookies oder in der URL abgelegt, daher spielt die Größe der Daten auch keine Rolle. Ein HttpSession-Objekt verwaltet einen Assoziativspeicher, der die Wertepaare speichert. Es ist günstig, die Elemente serialisierbar zu gestalten, um die Daten dauerhaft zu speichern.

Werfen wir abschießend einen Blick auf das Programmstück, das eine neue Ware hinzufügt:

List l = (List) session.getAttribute( "artikel" );

if ( l == null )
{
  l = new ArrayList();
  session.setAttribute( "artikel", l );
}
l.add( w );

interface javax.servlet.http.  HttpSession  

Object getAttribute( String name ) Liefert das mit name verbundene Objekt; null, wenn es keine Assoziation gab.

Enumeration getAttributeNames() Liefert eine Aufzählung aller mit der Sitzung verbundenen Objekte.

void setAttribute( String name, Object value ) Bindet name mit dem Objekt value an die Sitzung. Existierte das Objekt, so wird es ersetzt. Angemeldete HttpSessionBindingListener werden über die Methode value Bound() beziehungsweise valueUnbound() informiert.

void removeAttribute( String name ) Entfernt das Attribut von der Sitzung. Ungültige Namen werden ignoriert. HttpSession BindingListener werden durch Aufruf von valueUnbound() informiert.

Alle Methoden liefern eine IllegalStateException, wenn die Sitzung ungültig ist. Die Methoden putValue() und setValue() sind veraltet und wurden durch setAttribute() und getAttribute() ersetzt.

17.14.3 URL-Rewriting 

Das Session-Management sollte im Prinzip unabhängig von der technischen Umsetzung sein. Doch leider greift das Sitzungsmanagement bei URL-Rewriting schon sehr stark ein: Bei jedem Verweis auf eine neue Seite muss die URL entsprechend angepasst werden, denn man muss die Sitzungs-ID mitschicken. Cookies verwalten die Sitzungs-ID völlig anders. Das bedeutet, werden Cookies eingesetzt, dann ändert sich die URL nicht und jeder kann problemlos auf eine neue Seite verweisen. Nur bei URL-Rewriting muss an die URL eine Sitzungskennung angehängt werden.

Wenn wir innerhalb eines Servlets auf eine andere generierte Seite verweisen wollen, so haben wir eine URL vor uns, zu der wir verzweigen möchten. Die Servlet-API kümmert sich darum, dass zu einer Benutzer-URL die Sitzungs-ID automatisch angehängt wird. Dazu dienen die HttpServletResponse-Methode encodeURL() oder encodeRedirectURL().

<form action=’<%= response.encodeURL("/validate.jsp") %>’>

Werden der Verweis und die Kodierung aus Versehen vergessen, dann ist dies das Ende der Sitzung. Ob eine Sitzung mit einem Cookie behandelt wird, lässt sich mit isRequestedSessionIdFromCookie() testen. Dann kann aufgrund einer Fallunterscheidung encodeURL() verwendet werden oder nicht. Allgemein ist es aber nicht schlecht, wenn grundsätzlich alle Verweise innerhalb einer Webapplikation mit encodeURL() gesichert werden. Zwar wird im Fall von Cookies keine Kennung angehängt, aber eine spätere Umstellung fällt dann leichter, wenn der Nutzer einmal Cookies ausschaltet.

17.14.4 Zusätzliche Informationen 

Ein Sitzungsobjekt verwaltet neben den assoziierten Daten noch weitere Informationen. Jede Sitzung bekommt eine eindeutige ID, die sich mit getId() erfragen lässt. Ist die Sitzung neu, und der Client hat noch nie eine Verbindung gehabt, so gibt isNew() den Wert true zurück. Existiert dann die Sitzung, gibt getCreationTime() ein long zurück – kodiert sind wie üblich die vergangenen Millisekunden seit dem 1.1.1970 –, in dem sich das Erstellungsdatum erfragen lässt. Dagegen erfragt getLastAccessedTime() die Zeit, die seit dem letzen Zugriff durch den Client vergangen ist. Falls der Server die Informationen dauerhaft speichert und der Cookie nicht abläuft, erlaubt dies Meldungen der Art: »Schön, Sie nach zwei Wochen zum fünften Mal bei unserer Partnervermittlung wiederzusehen. Hat's wieder nicht geklappt?«

Das Ende der Sitzung

Eine Sitzung ist nicht automatisch für unendlich lange gültig. Bei Cookies lässt sich der Gültigkeitszeitraum einstellen. Auch Sitzungsobjekte lassen sich in der Zeit anpassen. Die Methode setMaxInactiveInterval() setzt den Wert, den eine Sitzung gültig ist. Ist der Wert negativ, zeigt er an, dass die Sitzung nicht automatisch beendet wird. Die entsprechende Methode getMaxInactiveInterval() liefert die Zeit in Sekunden, in der eine Sitzung gültig ist.

interface javax.servlet.http.  HttpSession  

long getCreationTime() Gibt in Millisekunden ab dem 1.1.1970 an, wann die Sitzung eröffnet wurde.

String getId() Liefert eine eindeutige Kennung, welche die Sitzung identifiziert.

long getLastAccessedTime() Gibt in Millisekunden ab dem 1.1.1970 zurück, wann der Client zum letzten Mal auf den Server zugegriffen hat.

int getMaxInactiveInterval() void setMaxInactiveInterval( int interval ) Liefert und setzt die Zeit, für die der Servlet-Container die Sitzung aufrechterhalten soll, bis sie ungültig wird.

boolean isNew() Der Rückgabewert ist true, wenn die Sitzung neu ist.

Listing 17.18   sessionTracking.jsp

<%@ page language="java" import="java.util.*" %>

<%
  int cnt = 0;

  if ( session.isNew() )
  {
    out.println( "Willkommen Neuling!\n" );
  }
  else
  {
    out.println( "Hallo alter Freund!\n" );

    String o = (String) session.getAttribute( "cnt" );

    if ( o != null )
      cnt = Integer.parseInt( o );

    cnt++;
  }

  session.setAttribute( "cnt", ""+cnt );
%>
 <p>

 Session-ID: <%= session.getId() %> <p>

 Erzeugt am: <%= new Date(session.getCreationTime()) %> <p>

 Letzter Zugriff: <%= new Date(session.getLastAccessedTime()) %> <p>

 Ungültig in Minuten: <%= session.getMaxInactiveInterval()/60  %> <p>

 Anzahl Zugriffe: <%= cnt %>

Das Programm liefert beispielsweise folgende Ausgabe:

Hallo alter Freund!
ID: 91410050092487D9B5D0D2A7A3D0F072
Erzeugt am: Fri Jan 18 20:16:49 CET 2002
Letzter Zugriff: Fri Jan 18 20:23:33 CET 2002
Ungültig in Minuten: 30
Anzahl Zugriffe: 4

Die ID sieht bei jedem Server anders aus. Der Web-Server von Sun erzeugt beispielsweise ganz andere Kennungen.

Mögliche Sicherheitsprobleme mit der ID

Die Sitzungsnummer, die wir auf dem Sitzungsobjekt mit getID() erfragen können, macht nicht bei jedem Servlet-Container eine vertrauensvolle Figur. Denn wenn wir diese erzeugen könnten, so wäre es möglich, unter einer fremden ID Aktionen durchzuführen. Es dürfte selbstverständlich sein, dass das vermieden werden muss. Unter der Servlet-API lässt sich die Berechnung der ID leider nicht anpassen, so dass wir auf eine gute Zufallsgenerierung vertrauen müssen. Diese ist bei Tomcat gegeben, denn die Methode generateSessionId() ruft eine Methode generateId() im SessionIdGenerator auf, die sehr gute Zahlen mit Hilfe der Klasse java.security.SecureRandom konstruiert.

h7pueqoxj1. vl7614oxj2, an8kmdoxj3, kzsy0poxj4
qgstxvoxj5, meay0toxj6, sdtltaoxj7, uy3n6uoxj8
D2thahoxj9, ppg4vroxja

Die ID besteht aus sechs Zufallszeichen, drei mit der aktuellen Zeit kodierten Zeichen und einem Zähler, der bei 1 beginnt.

Bei anderen Servern bleibt nur die Lösung, auf HttpSession zu verzichten und mit Cookies eigene IDs zu verwalten.