19.11 Sitzungsverfolgung (Session Tracking)

Jeder Auftrag an den Webserver wird unabhängig von anderen Aufträgen verwaltet. Wenn wir beispielsweise eine Seite neu laden oder einen Verweis verfolgen, weiß der Server nicht (beziehungsweise interessiert sich nicht dafür), dass die Anfrage von uns kam. Was an diesem Verhalten deutlich wird, ist das Fehlen eines Zustands. Es fehlt also die Möglichkeit, dass ein Client vom Server identifiziert wird und einem aktuellen Zustand des bidirektionalen Kommunikationsverlaufes zugeordnet werden kann. Der Zustand bezieht sich hier auf eine nicht-existente serverseitige Information. Aus diesem Grund wird HTTP auch als zustandsloses Protokoll bezeichnet. Dass dies aber nicht immer wünschenswert ist und sogar einen Nachteil darstellen kann, sehen wir an unterschiedlichen Anforderungen:

• Ein Warenkorb für den Einkauf. In Online-Systemen wird ein Einkaufswagen gefüllt, und unterschiedliche Webseiten informieren Kaufwillige über die Produkte. Wenn der Server allerdings die Seitenanfrage dem Client nicht zuordnen kann, ist es nicht möglich, den Warenkorb zu füllen.

• Individualisierung. Bei privaten Seiten muss sich ein Benutzer anmelden, um die Angebote nutzen zu können. Es ist unpraktisch, wenn er sich bei jedem Seitenwechsel neu authentifizieren muss. Verlässt ein Kunde das System auf einer bestimmten Seite, kann Ersteres nach einem erneuten Anmelden den Benutzer wieder zurück auf diese Seite führen. Hat der Kunde per Suchmaschine eine Ware gesucht, die nicht verfügbar war, kann sich dies nach einer Weile geändert haben. Das System sollte dem Benutzer dann die Information geben, dass seine Ware nun verfügbar ist.

• Demoskopie. Das System eignet sich auch für die Benutzerüberwachung. Besucht ein Benutzer eine Seite mehrmals, kann der Betreiber dies erkennen und diese Information mit einem »Ist-Beliebt-Faktor« verbinden. Diese Information lässt sich natürlich kommerziell gut nutzen.

19.11.1 Lösungen für Sitzungsverfolgung

Es ist also ein System gesucht, das es dem Server erlaubt, den Client zu identifizieren, auch wenn HTTP ein zustandsloses Protokoll ist. Als Lösungen bieten sich an:

• Cookies. Ein Cookie speichert eine Kennung, sodass 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 einige Schwächen. Dem Servlet fällt 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 Voreinstellung, 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 Serverseite 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 beim Versenden automatisch mitgeschickt werden. Dies sieht etwa so aus:

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

Diese versteckten Informationen können auch genutzt werden, um eine Sitzungs-ID mitzuschicken. Der Vorteil ist, dass wir wieder keine Cookies benötigen und die URL nicht länger wird, der Nachteil, dass die Information immer dynamisch mit eingebaut werden muss.

Cookies erlauben dem Server, den Client wiederzuerkennen und ihn einer Sitzung zuzuordnen, doch haben wir 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.

19.11.2 Auf Session-Dateien zurückgreifen

Die impliziten EL-Objekte pageScope, requestScope, sessionScope und applicationScope ermöglichen den Zugriff auf die Daten, die in einem Gültigkeitsbereich liegen. Für Daten einer Session nutzen wir die Variable sessionScope.

<% session.put( "url", "www.tutego.com" ); %> 
${sessionScope.url}

Ihr Kommentar