14.9 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 die Seitenanfrage einem Client nicht zuordnen kann, ist es nicht möglich, den Warenkorb individuell zu füllen.
• Individualisierung: Benutzer können auf sie persönlich zugeschnittene Webseiten sehen und etwa das Wetter auf Bali auf der Startseite auswählen sowie die Fußballergebnisse von Schalke 04.
• 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.

14.9.1 Lösungen für die 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 schwerwiegendes 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 ist, dass die Information immer dynamisch mit eingebaut werden muss.

14.9.2 Sitzungen in JSPs

Verbindet sich ein Browser zum ersten Mal mit einer JSP, so erzeugt der Servlet-Container automatisch eine neue Sitzung und sendet standardmäßig einen Cookie zurück. Client und Server tauschen dann bei allen weiteren Anfragen diesen Cookie aus, sodass der Server den Client wiedererkennen kann. Wenn der Benutzer Cookies ablehnt, müssen wir eine zweite Implementierung anbieten, die Sitzungsinformationen an die URL anhängt, aber das soll jetzt kein Thema sein.

14.9.3 Auf Session-Dateien zurückgreifen

Der Cookie, den der Server automatisch generiert, enthält eine ID, und diese ID ist mit einem Assoziativspeicher verbunden. In diesen Assoziativspeicher können wir Schlüssel/Werte-Paare setzen oder Werte über die Schlüssel erfragen. Für den Assoziativspeicher gibt es in der EL die implizite Variable sessionScope – sie bietet alle Daten einer Sitzung. Zusammenfassend lässt sich festhalten, dass die unterschiedlichen impliziten EL-Objekte pageScope, requestScope, sessionScope und applicationScope alle jeweils Zugriffe auf Daten in unterschiedlichen Gültigkeitsbereichen ermöglichen.

<% session.setAttribute( "url", "www.tutego.com" ); %>
Die URL in der Session was: ${sessionScope.url}.

<% session.invalidate(); %>

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.