Übersicht über den ASP.NET-Sitzungszustand

Aktualisiert: November 2007

Mit dem ASP.NET-Sitzungszustand können Sie Werte für einen Benutzer speichern und abrufen.

Dieses Thema enthält folgende Abschnitte:

• Hintergrund

• Codebeispiele

• Klassenreferenz

Hintergrund

Mit dem ASP.NET-Sitzungszustand können Sie Werte für einen Benutzer speichern und abrufen, während dieser durch die ASP.NET-Seiten einer Webanwendung navigiert. HTTP ist ein statusfreies Protokoll. Dies bedeutet, dass ein Webserver jede HTTP-Anforderung für eine Seite als unabhängige Anforderung behandelt. Der Server kennt die bei früheren Anforderungen verwendeten Variablenwerte nicht. Anforderungen, die innerhalb eines bestimmten Zeitraums vom selben Browser stammen, werden vom ASP.NET-Sitzungszustand als eine Sitzung erfasst. Die Variablenwerte können für die Dauer einer solchen Sitzung beibehalten werden. Der ASP.NET-Sitzungszustand ist für alle ASP.NET-Anwendungen standardmäßig aktiviert.

Zu den Alternativen zum Sitzungszustand gehören folgende Möglichkeiten:

• Der Anwendungszustand, mit dem Variablen gespeichert werden, auf die alle Benutzer einer ASP.NET-Anwendung zugreifen können.

• Profileigenschaften, durch die Benutzerwerte in einem Datenspeicher gespeichert werden, ohne dass sie ungültig werden.

• Die ASP.NET-Zwischenspeicherung, mit der Werte im Arbeitsspeicher gespeichert werden, der allen ASP.NET-Anwendungen zur Verfügung steht.

• Der Ansichtszustand, mit dem Werte in einer Seite erhalten bleiben.

• Cookies

• Die Abfragezeichenfolge und die Felder auf einem HTML-Formular, die bei einer HTTP-Anforderung zur Verfügung stehen.

Einen Vergleich der verschiedenen Zustandsverwaltungsoptionen finden Sie unter Empfehlungen zur ASP.NET-Zustandsverwaltung.

Sitzungsvariablen

Sitzungsvariablen werden in einem SessionStateItemCollection-Objekt gespeichert, das über die HttpContext.Session- Eigenschaft verfügbar gemacht wird. Auf einer ASP.NET-Seite werden die aktuellen Sitzungsvariablen über die Session-Eigenschaft des Page-Objekts zur Verfügung gestellt.

Die Sitzungsvariablenauflistung wird nach den Variablennamen oder mit einem ganzzahligen Index indiziert. Sitzungsvariablen werden erstellt, indem Sie mit einem Namen auf die Sitzungsvariable verweisen. Eine Sitzungsvariable muss nicht deklariert oder explizit zur Auflistung hinzugefügt werden. Im folgenden Beispiel wird gezeigt, wie Sitzungsvariablen auf einer ASP.NET-Seite für den Vor- und Nachnamen eines Benutzers erstellt werden und die aus TextBox-Steuerelementen abgerufenen Werte erhalten.

Session("FirstName") = FirstNameTextBox.Text
Session("LastName") = LastNameTextBox.Text

Session["FirstName"] = FirstNameTextBox.Text;
Session["LastName"] = LastNameTextBox.Text;

Jeder gültige .NET Framework-Typ kann für Sitzungsvariablen verwendet werden. Im folgenden Beispiel wird ein ArrayList-Objekt in einer Sitzungsvariable mit dem Namen StockPicks gespeichert. Der von der StockPicks-Sitzungsvariable zurückgegebene Wert muss beim Abrufen aus SessionStateItemCollection in den entsprechenden Typ umgewandelt werden.

' When retrieving an object from session state, cast it to 
' the appropriate type.
Dim stockPicks As ArrayList = CType(Session("StockPicks"), ArrayList)

' Write the modified stock picks list back to session state.
Session("StockPicks") = stockPicks

// When retrieving an object from session state, cast it to 
// the appropriate type.
ArrayList stockPicks = (ArrayList)Session["StockPicks"];

// Write the modified stock picks list back to session state.
Session["StockPicks"] = stockPicks;

Hinweis:
Wenn ein anderer Sitzungszustandsmodus als InProc verwendet wird, muss der Typ der Sitzungsvariablen entweder ein primitiver .NET-Typ oder serialisierbar sein. Das liegt daran, dass der Wert der Sitzungsvariablen in einem externen Datenspeicher gespeichert wird. Weitere Informationen finden Sie unter Sitzungszustandsmodi.

Sitzungs-IDs

Sitzungen werden durch einen eindeutigen Bezeichner gekennzeichnet, der mithilfe der SessionID-Eigenschaft gelesen werden kann. Bei aktiviertem Sitzungszustand wird jede Anforderung für eine Seite der ASP.NET-Anwendung auf einen vom Browser gesendeten SessionID-Wert überprüft. Wenn kein SessionID-Wert angegeben ist, startet ASP.NET eine neue Sitzung. Der SessionID-Wert dieser Sitzung wird zusammen mit der Antwort an den Browser gesendet.

Standardmäßig werden SessionID-Werte in einem Cookie gespeichert. Für Sitzungen ohne Cookies kann die Anwendung jedoch auch so konfiguriert werden, dass die SessionID-Werte in der URL gespeichert werden.

Eine Sitzung gilt so lange als aktiv, wie Anforderungen mit gleichem SessionID-Wert gestellt werden. Wenn die Zeit zwischen den Anforderungen einer bestimmten Sitzung den festgelegten Timeoutwert in Minuten überschreitet, gilt die Sitzung als abgelaufen. Für Anforderungen, die mit einem abgelaufenen SessionID-Wert ausgeführt werden, wird eine neue Sitzung gestartet.

Sicherheitshinweis:

P:System.Web.SessionState.HttpSessionState.SessionID-Werte werden im Klartext übertragen, unabhängig davon, ob sie als Cookie oder als Teil der URL gesendet werden. Ein Benutzer mit bösartigen Absichten könnte sich Zugriff auf die Sitzung eines anderen Benutzers verschaffen, indem er den SessionID-Wert abruft und in Anforderungen an den Server einschließt. Beim Speichern von vertraulichen Informationen im Sitzungszustand wird empfohlen, jede Kommunikation zwischen Browser und Server, in der der SessionID-Wert enthalten ist, unter Verwendung von SSL zu verschlüsseln.

Sitzungs-IDs ohne Cookies

Standardmäßig wird der SessionID-Wert im Browser in einem Sitzungscookie gespeichert, der nicht abläuft. Sie können jedoch festlegen, dass Sitzungs-IDs nicht in Cookies gespeichert werden, indem Sie in der Datei Web.config im Abschnitt sessionState dem cookieless-Attribut den Wert true zuweisen.

Das folgende Beispiel zeigt eine Web.config-Datei, mit der eine ASP.NET-Anwendung für die Verwendung von Sitzungs-IDs ohne Cookies konfiguriert wird.

<configuration>
  <system.web>
    <sessionState cookieless="true"
      regenerateExpiredSessionId="true" />
  </system.web>
</configuration>

Um den Sitzungszustand bei Sitzungen ohne Cookies aufrechtzuerhalten, fügt ASP.NET automatisch eine eindeutige Sitzungs-ID in die URL der Seite ein. In folgender URL beispielsweise wurde von ASP.NET die eindeutige Sitzungs-ID lit3py55t21z5v55vlm25s55 eingefügt:

http://www.example.com/(S(lit3py55t21z5v55vlm25s55))/orderform.aspx

Wenn ASP.NET eine Seite an den Browser sendet, werden alle Links auf der Seite geändert, die einen Pfad relativ zur Anwendung verwenden. Dabei wird ein Sitzungs-ID-Wert in den Links eingebettet. (Links mit absoluten Pfaden werden nicht geändert.) Der Sitzungszustand bleibt erhalten, solange der Benutzer auf Links klickt, die auf diese Weise geändert wurden. Wenn vom Client jedoch eine von der Anwendung bereitgestellte URL geändert wird, kann ASP.NET die Sitzungs-ID möglicherweise nicht auflösen und die Anforderung einer bestehenden Sitzung zuordnen. In diesem Fall wird für die Anforderung eine neue Sitzung gestartet.

Die Sitzungs-ID wird nach dem Schrägstrich eingefügt, der dem Anwendungsnamen folgt, und geht jedem weiteren Bezeichner für eine Datei oder ein virtuelles Verzeichnis voraus. Auf diese Weise kann ASP.NET den Anwendungsnamen auflösen, bevor das SessionStateModule für die Anforderung gestartet wird.

Hinweis:
Um die Sicherheit Ihrer Anwendung zu verbessern, sollten sich die Benutzer abmelden können. Daraufhin sollte die Anwendung die Abandon-Methode aufrufen. Dies verringert das Risiko, dass ein Benutzer mit bösartigen Absichten Zugriff auf den eindeutigen Bezeichner in der URL erhält, um damit in der Sitzung gespeicherte private Benutzerdaten abzurufen.

Erneutes Generieren von abgelaufenen Sitzungs-IDs

Standardmäßig werden die Werte von Sitzungs-IDs in Sitzungen ohne Cookies wiederverwendet. Das bedeutet, dass eine neue Sitzung unter Verwendung des mit der Anforderung bereitgestellten SessionID-Werts gestartet wird, wenn eine Anforderung mit einer abgelaufenen Sitzungs-ID gestellt wird. Enthält ein von mehreren Browsern verwendeter Link einen SessionID-Wert, der nicht in einem Cookie gespeichert wurde, kann dies zu einer unbeabsichtigt freigegebenen Sitzung führen. (Dies kann auftreten, wenn der Link über eine Suchmaschine, eine E-Mail oder ein anderes Programm übergeben wird.) Sie können die Möglichkeit der Freigabe von Sitzungsdaten verringern, indem Sie die Anwendung so konfigurieren, dass Sitzungs-IDs nicht wiederverwendet werden. Legen Sie dazu das regenerateExpiredSessionId-Attribut des sessionState-Konfigurationselements auf true fest. Dadurch wird eine neue Sitzungs-ID generiert, wenn eine Sitzungsanforderung ohne Cookies mit einer abgelaufenen Sitzungs-ID gesendet wird.

Hinweis:
Wenn die mit der abgelaufenen Sitzungs-ID erstellte Anforderung mithilfe der HTTP-Methode POST gesendet wird, gehen alle gesendeten Daten verloren, wenn regenerateExpiredSessionId den Wert true hat. Das liegt daran, dass ASP.NET eine Umleitung durchführt, um sicherzustellen, dass der Browser die neue Sitzungs-ID in der URL enthält.

Benutzerdefinierte Sitzungs-IDs

Sie können eine benutzerdefinierte Klasse implementieren, um SessionID-Werte bereitzustellen und zu überprüfen. Erstellen Sie zu diesem Zweck eine Klasse, die von der SessionIDManager-Klasse erbt, und überschreiben Sie die Methoden CreateSessionID und Validate mit Ihren Implementierungen. Ein entsprechendes Beispiel ist das für die CreateSessionID-Methode zur Verfügung gestellte Beispiel.

Sie können die SessionIDManager-Klasse ersetzen, indem Sie eine Klasse erstellen, die die ISessionIDManager-Schnittstelle implementiert. Sie verfügen z. B. über eine Webanwendung, in der Seiten ohne ASP.NET (z. B. HTML-Seiten oder Bilder) mithilfe eines ISAPI-Filters ein eindeutiger Bezeichner zugewiesen wird. Sie können eine benutzerdefinierte SessionIDManager-Klasse implementieren, um diesen eindeutigen Bezeichner mit dem ASP.NET-Sitzungszustand zu verwenden. Wenn die benutzerdefinierte Klasse Sitzungs-IDs ohne Cookies unterstützt, muss eine Lösung zum Senden und Abrufen von Sitzungs-IDs in der URL implementiert werden.

Sitzungsmodi

Der ASP.NET-Sitzungszustand unterstützt mehrere Speicheroptionen für Sitzungsvariablen. Jede Option wird als Mode-Typ des Sitzungszustands bezeichnet. Standardmäßig werden Sitzungsvariablen im Speicherbereich des ASP.NET-Workerprozesses gespeichert. Sie können jedoch auch festlegen, dass der Sitzungszustand in einem separaten Prozess, in einer SQL Server-Datenbank oder in einer benutzerdefinierten Datenquelle gespeichert werden soll. Wenn Sie den Sitzungszustand für die Anwendung nicht aktivieren möchten, können Sie den Sitzungsmodus auf Off festlegen.

Weitere Informationen finden Sie unter Sitzungszustandsmodi.

Sitzungsereignisse

In ASP.NET werden zwei Ereignisse zur Verfügung gestellt, die Ihnen helfen, Benutzersitzungen zu verwalten. Das Session_OnStart-Ereignis wird ausgelöst, wenn eine neue Sitzung gestartet wird. Das Session_OnEnd-Ereignis wird ausgelöst, wenn eine Sitzung abgebrochen wird oder abläuft. Die Sitzungsereignisse einer ASP.NET-Anwendung werden in der Datei Global.asax festgelegt.

Das Session_OnEnd-Ereignis wird nicht unterstützt, wenn die Mode-Eigenschaft der Sitzung auf einen anderen Wert als InProc festgelegt wird. Dies ist der Standardmodus.

Hinweis:

Wenn an der Datei Global.asax oder der Datei Web.config einer ASP.NET-Anwendung Änderungen vorgenommen werden, wird die Anwendung neu gestartet, und alle im Anwendungszustand oder Sitzungszustand gespeicherten Werte gehen verloren. Berücksichtigen Sie, dass einige Virenschutzprogramme Datum und Uhrzeit der letzten Änderung für die Datei Global.asax bzw. die Datei Web.config einer Anwendung ändern können.

Weitere Informationen finden Sie unter Ereignisse des Sitzungszustands.

Konfigurieren des Sitzungszustands

Der Sitzungszustand wird mithilfe des sessionState-Elements im system.web-Konfigurationsabschnitt konfiguriert. Der Sitzungszustand kann auch mithilfe des EnableSessionState-Werts in der @ Page-Direktive konfiguriert werden.

Unter Verwendung des sessionState-Elements können folgende Optionen angegeben werden:

• Der Modus, in dem die Sitzung Daten speichert.

• Die Art und Weise, in der Sitzungs-ID-Werte zwischen Client und Server gesendet werden.

• Der Timeout-Wert der Sitzung.

• Unterstützende Werte, die auf der Mode-Einstellung der Sitzung basieren.

Im folgenden Beispiel wird ein sessionState-Element dargestellt, mit dem eine Anwendung für den SQLServer-Sitzungsmodus konfiguriert wird. Mit diesem Element wird der Timeout-Wert auf 30 Minuten festgelegt. Außerdem legt es fest, dass Sitzungs-IDs in der URL gespeichert werden.

<sessionState mode="SQLServer"
  cookieless="true "
  regenerateExpiredSessionId="true "
  timeout="30"
  sqlConnectionString="Data Source=MySqlServer;Integrated Security=SSPI;"
  stateNetworkTimeout="30"/>

Sie können den Sitzungszustand für eine Anwendung deaktivieren, indem Sie den Sitzungszustandsmodus auf Off festlegen. Wenn der Sitzungszustand nur für eine bestimmte Seite der Anwendung deaktiviert werden soll, kann der EnableSessionState-Wert in der @ Page-Direktive auf false festgelegt werden. Der EnableSessionState-Wert kann auch auf ReadOnly festgelegt werden, um schreibgeschützten Zugriff auf Sitzungsvariablen zu ermöglichen.

Gleichzeitige Anforderungen und Sitzungszustand

Der Zugriff auf den ASP.NET-Sitzungszustand erfolgt sitzungsspezifisch. Wenn zwei Benutzer gleichzeitig eine Anforderung stellen, erhalten beide gleichzeitig Zugriff auf eine jeweils eigene Sitzung. Wenn jedoch zwei gleichzeitige Anforderungen für die gleiche Sitzung gesendet werden (durch Verwendung des gleichen SessionID-Werts), erhält die erste Anforderung exklusiven Zugriff auf die Sitzungsinformationen. Die zweite Anforderung wird erst ausgeführt, nachdem die erste Anforderung beendet wurde. (Die zweite Sitzung kann ebenfalls Zugriff erhalten, wenn die exklusive Sperre der Informationen aufgehoben wird, da der Timeout der Sperre von der ersten Anforderung überschritten wurde.) Wenn der EnableSessionState-Wert in der @ Page-Direktive auf ReadOnly festgelegt ist, werden die Sitzungsdaten durch eine Anforderung der schreibgeschützten Sitzungsinformationen nicht exklusiv gesperrt. Doch auch schreibgeschützte Anforderungen von Sitzungsdaten müssen unter Umständen warten, bis eine Sperre, die durch eine Lese-/Schreibanforderung von Sitzungsdaten festgelegt wurde, aufgehoben wird.

Zurück nach oben

Codebeispiele

Gewusst wie: Speichern von Werten im Sitzungszustand

Gewusst wie: Lesen von Werten aus dem Sitzungszustand

Implementieren eines Sitzungszustandsspeicher-Anbieters

Zurück nach oben

Klassenreferenz

In der folgenden Tabelle sind wesentliche Klassen in Bezug auf den Sitzungszustand im System.Web.SessionState-Namespace aufgelistet.

Zurück nach oben

Siehe auch

Konzepte

Implementieren eines Sitzungszustandsspeicher-Anbieters