Überblick

Mit ASP steht Ihnen ein sehr leistungsstarkes und komfortables Objekt zur Verwaltung von Sitzungen zur Verfügung. Sie können auf einfache Weise benutzerbezogene Variablen und Objekte speichern, die seitenübergreifend zur Verfügung stehen. Sitzungen werden in ASP automatisch gestartet und nach einer frei wählbaren Zeitspanne ohne Zugriffe automatisch beendet. Beim Start und Ende einer Sitzung werden Ereignisse ausgelöst, die es Ihnen ermöglichen, zu diesen Zeitpunkten eigene Aktionen ausführen zu lassen.

Insgesamt kann man das Session-Konzept der Active Server Pages als sehr gelungen bezeichnen, es gibt aber leider einen Wermutstropfen – zur Realisierung werden Cookies eingesetzt.

Wie funktionieren Sessions intern?

Sitzungen werden in ASP durch eindeutige Session-Cookies identifiziert. Das Cookie selbst enthält nur eine eindeutige Sitzungskennung, die zwischen dem Browser des Clients und dem Server ausgetauscht wird und eine eindeutige Zuordnung der Anfrage zu der entsprechenden Sitzung ermöglicht.
Die eigentlichen Daten des Session-Objektes werden im Speicher des Webservers abgelegt. Dies hat einerseits den Vorteil, dass nur ein relativ kleines Datenpaket übertragen werden muss, andererseits die im Session-Objekt gespeicherten Daten verborgen bleiben und damit vor direkten Zugriffen des Anwenders geschützt sind.

Eine neue Sitzung wird durch den Aufruf einer beliebigen ASP-Seite der Anwendung gestartet. Als erstes wird eine neue, eindeutige Sitzungsidentifikation vergeben, auf die Sie mittels Session.SessionID zugreifen können; bei dieser ID handelt es sich einfach um einen fortlaufenden Zähler.
Anschließend wird die Session_OnStart-Methode in der Datei global.asa aufgerufen und dem Browser in der Antwort automatisch ein temporäres Cookie gesendet, dass eine eindeutige Sitzungskennung enthält, die folgendermaßen aufgebaut ist:

ASPSESSIONIDGQGGGNBG=LPPPHIMBDECFMCLIFPLPOJNP

Versuchen Sie gar nicht erst, einen Zusammenhang zwischen dem Wert des Cookies und der internen SessionID herauszufinden. Um es Hackern unmöglich zu machen, durch Probieren einen Cookie zu finden, der zu einer gültigen SessionID passt, wird der Aufbau der Cookies wohl immer eines der best gehütetsten Geheimnisse bleiben.
Es ist anscheinend sogar so, dass es zwischen diesen Werten gar keinen direkten (mathematischen) Zusammenhang gibt, da ASP beim Start einer neuen Sitzung zwar eine neue interne SessionID vergibt, das bisherige Cookie aber unverändert beibehalten wird.

Eine typische Antwort des Servers beim Start einer neuen Sitzung könnte wie folgt aussehen:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Sun, 10 Mar 2002 12:11:15 GMT
Connection: Keep-Alive
Content-Length: 135
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQQGQXRQ=IHPNBGKBGHOEHBPFGDFIAOGG; path=/
Cache-control: private

Dem Browser wird durch die Antwort ein neues Cookie übermittelt. Dieses ist zwar nur temporär und verfällt beim Schließen des Browser automatisch, stößt bei einigen Benutzern aber trotzdem auf so große Widerstände, dass diese die Annahme sämtlicher Cookies pauschal verweigern.

Lehnt ein Anwender die Annahme des Session-Cookies ab, ist es nicht möglich, die Funktionalität des Session-Objektes zu nutzen. Eine manuelle Übergabe der SessionID im Querystring oder versteckten Formularfeldern, wie sie in PHP oder ASP.NET zur Verfügung steht, wurde von Microsoft leider nicht vorgesehen. Für diesen Fall müssen also Alternativen gefunden werden.

Alternativen

Eine Möglichkeit wäre, komplett auf Sessions zu verzichten und alle Daten per Querystring oder Formularfeldern an die nächste Seite weiterzureichen. Ein anderer Ausweg bietet sich durch den Einsatz einer eigenen Sitzungsverwaltung, die sich z.B. datenbankgestützt realisieren lässt.
Neben dem zusätzlichen Aufwand oder den zusätzlichen Kosten bei Einsatz einer Lösung von Drittanbietern muss man hierbei allerdings häufig auch Abstriche bei der Funktionalität machen, so wird in den meisten Fällen keine Speicherung von Objekten unterstützt und der Sitzungsstatus geht beim Aufruf von statischen HTML-Seiten verloren.

Mit dem IIS 4 hat Microsoft selbst eine Lösung dieses Problems vorgeschlagen. Durch den Einsatz des Cookie-Munger-Filters kann an alle in der Seite vorhandenen Links automatisch eine SessionID angefügt werden. Neben einigen funktionalen Einschränkungen macht es sich mit Blick auf die Performance aber teilweise deutlich bemerkbar, dass alle Antworten des Servers komplett durchsucht und bearbeitet werden müssen.

Wir haben daher nach einer Lösung gesucht, die folgende Kriterien erfüllt:

• minimaler Anpassungsaufwand für bestehende Web-Sites
• hohe Funktionaliät und Kompatibität zum originalen Session-Objekt
• minimale Performanceeinbußen