ASP-Vortragsreihe (19) Sitzungen verwalten
Autor：Eve Cole
Aktualisierungszeit：2009-05-30 19:58:38
Eine der Herausforderungen bei der erfolgreichen Entwicklung von Webanwendungen besteht darin, Benutzerinformationen beizubehalten, während der Benutzer während eines Benutzerbesuchs oder einer Benutzersitzung von Seite zu Seite in einer Anwendung springt. HTTP ist ein zustandsloses Protokoll, was bedeutet, dass der Webserver jeden Zugriff auf eine Seite als unabhängigen Zugriff behandelt; der Server speichert keine Informationen über den vorherigen Zugriff, selbst wenn der Zugriff innerhalb weniger Sekunden nach dem aktuellen Zugriff erfolgt vor. Dieser Mangel an Erinnerung an frühere Besuche macht es schwierig, Anwendungen wie Online-Kataloge zu schreiben, die möglicherweise den Überblick über Katalogelemente behalten müssen, die ein Benutzer beim Wechseln zwischen verschiedenen Seiten des Katalogs ausgewählt hat.
ASP bietet eine einzigartige Lösung für die Verwaltung von Sitzungsinformationsproblemen. Mithilfe des ASP-Sitzungsobjekts und einer speziellen, von Ihrem Server generierten Benutzer-ID können Sie eine intelligente Anwendung erstellen, die jeden eingehenden Benutzer identifizieren und Informationen sammeln kann, die von der Anwendung verwendet werden, um die Präferenzen oder Inhaltsauswahlen des Benutzers zu verfolgen.
ASP legt die Benutzer-ID über HTTP-Cookies fest. HTTP-Cookies sind kleine Dateien, die im Browser des Benutzers gespeichert werden. Wenn Sie daher eine Anwendung für einen Browser erstellen, der keine Cookies unterstützt, oder wenn Ihre Kunden ihre Browser so eingestellt haben, dass sie keine Cookies akzeptieren, verwenden Sie nicht die Sitzungsverwaltungsfunktion von ASP.
Sie können auch Skripts schreiben, die ausgeführt werden, wenn die Anwendung startet oder endet.
Sitzungen starten und beenden Sitzungen können auf drei Arten gestartet werden:
Ein neuer Benutzer fordert Zugriff auf eine URL an, die eine ASP-Datei in einer Anwendung identifiziert, deren Global.asa-Datei die Session_OnStart-Prozedur enthält.
Der Benutzer speichert einen Wert im Session-Objekt.
Der Benutzer fordert die ASP-Datei einer Anwendung an und die Global.asa-Datei der Anwendung verwendet das <OBJECT>-Tag, um eine Instanz des Objekts mit Sitzungsbereich zu erstellen.
Wenn der Benutzer für einen bestimmten Zeitraum keine Seite in der Anwendung anfordert oder aktualisiert, wird die Sitzung automatisch beendet. Der Standardwert für diesen Zeitraum beträgt 20 Minuten. Sie können die Standardeinstellung für die Zeitüberschreitungsgrenze der Anwendung ändern, indem Sie die Eigenschaft „Sitzungszeitüberschreitung“ auf der Eigenschaftenseite „Anwendungsoptionen“ im Internetdienste-Manager festlegen. Dieser Wert sollte basierend auf den Anforderungen Ihrer Webanwendung und dem Speicherplatz des Servers festgelegt werden. Wenn Sie beispielsweise möchten, dass Benutzer, die Ihre Webanwendung durchsuchen, nur wenige Minuten auf jeder Seite bleiben, sollten Sie den Standardwert für das Sitzungszeitlimit verkürzen. Ein zu langer Sitzungszeitüberschreitungswert führt dazu, dass zu viele offene Sitzungen die Speicherressourcen Ihres Servers erschöpfen.
Wenn Sie für eine bestimmte Sitzung einen Timeout-Wert festlegen möchten, der kleiner als der Standard-Timeout-Wert ist, können Sie die Timeout-Eigenschaft des Session-Objekts festlegen. Das folgende Skript legt beispielsweise den Timeout-Wert auf 5 Minuten fest.
<%Session.Timeout = 5%>
Sie können auch einen Zeitüberschreitungswert festlegen, der über der Standardeinstellung liegt. Die Eigenschaft Session.Timeout bestimmt den Zeitüberschreitungswert.
Sie können eine Sitzung auch explizit über die Abandon-Methode des Session-Objekts beenden. Um beispielsweise eine Exit-Schaltfläche in einer Tabelle bereitzustellen, legen Sie den ACTION-Parameter der Schaltfläche auf die URL einer ASP-Datei fest, die den folgenden Befehl enthält.
<% Session.Abandon %>
Über SessionID und Cookies
Wenn ein Benutzer zum ersten Mal eine ASP-Datei in einer bestimmten Anwendung anfordert, generiert ASP eine SessionID. SessionID ist eine von einem komplexen Algorithmus generierte Zahl, die jede Benutzersitzung eindeutig identifiziert. Zu Beginn einer neuen Sitzung speichert der Server die Sitzungs-ID als Cookie im Webbrowser des Benutzers.
Eine SessionID ähnelt insofern einem Schlüssel, als ASP Benutzerinformationen in einem „Safe“ auf dem Server speichern kann, wenn der Benutzer während einer Sitzung mit der Anwendung interagiert. So wie ein Schlüssel für den Zugriff auf Elemente in einem Safe verwendet werden kann, kann auf den Inhalt des „Safes“ über das SessionID-Cookie des Benutzers zugegriffen werden, das im HTTP-Anforderungsheader gesendet wird. Immer wenn ASP eine Seitenanforderung empfängt, überprüft es den HTTP-Anforderungsheader, um das SessionID-Cookie zu erhalten.
Nachdem das SessionID-Cookie im Browser des Benutzers gespeichert wurde, verwendet ASP das Cookie weiterhin zum Verfolgen der Sitzung, selbst wenn der Benutzer eine andere ASP-Datei anfordert oder eine ASP-Datei anfordert, die in einer anderen Anwendung ausgeführt wird. Wenn der Benutzer die Sitzung absichtlich abbricht oder eine Zeitüberschreitung der Sitzung zulässt und dann eine andere ASP-Datei anfordert, startet ASP ebenfalls eine neue Sitzung mit demselben Cookie. Erst wenn der Serveradministrator den Server neu startet oder der Benutzer den Webbrowser neu startet, werden die im Speicher gespeicherten SessionID-Einstellungen gelöscht und der Benutzer erhält ein neues SessionID-Cookie.
Durch die Wiederverwendung des SessionID-Cookies minimiert ASP die Anzahl der an den Browser des Benutzers gesendeten Cookies. Wenn Sie alternativ entscheiden, dass Ihre ASP-Anwendung keine Sitzungsverwaltung erfordert, können Sie ASP daran hindern, Sitzungen zu verfolgen und Sitzungs-IDs an Benutzer zu senden.
ASP sendet unter folgenden Umständen keine Sitzungscookies:
Der Sitzungsstatus der Anwendung ist deaktiviert.
Eine ASP-Seite ist als sitzungslos definiert, d. h. die Seite enthält das Tag <%@ EnableSessionState=False %>.
Bitte beachten Sie, dass das SessionID-Cookie keine dauerhafte Methode zur Verfolgung eines Benutzers über mehrere Besuche einer Website hinweg bietet. Im Serverspeicher gespeicherte Sitzungs-ID-Informationen können leicht verloren gehen. Wenn Sie Benutzer verfolgen möchten, die Ihre Webanwendung im Laufe der Zeit besuchen, müssen Sie eine Benutzeridentität erstellen, indem Sie ein spezielles Cookie im Webbrowser des Benutzers speichern und die Cookie-Informationen in einer Datenbank speichern.
Speichern Sie Daten im Sitzungsobjekt
Das Session-Objekt stellt ein dynamisches assoziatives Array bereit, in dem Informationen gespeichert werden können. Sie können numerische Variablen und Objektvariablen in Sitzungsobjekten speichern.
Variablen können in einem Session-Objekt gespeichert werden, indem benannten Elementen im Session-Objekt Werte zugewiesen werden. Der folgende Befehl speichert beispielsweise zwei neue Variablen im Session-Objekt:
<%
Session("Vorname") = "Jeff"
Session("LastName") = "Smith"
%>
Informationen können vom Session-Objekt abgerufen werden, indem auf dieses benannte Element zugegriffen wird. Zeigen Sie beispielsweise den aktuellen Wert von Session("FirstName") an:
Willkommen <%= Session("FirstName") %>
Sie können die Präferenzen des Benutzers im Session-Objekt speichern und dann auf die Präferenzen zugreifen, um zu entscheiden, welche Seite an den Benutzer gesendet werden soll. Beispielsweise können Sie Benutzern erlauben, auf der ersten Seite Ihrer Anwendung eine reine Textversion des Inhalts anzugeben und diese Auswahl auf alle nachfolgenden Seiten der Anwendung anzuwenden, die der Benutzer besucht.
<% If Session("ScreenResolution") = "Low" Then %>
Dies ist die Textversion der Seite.
<%Else%>
Dies ist die Multimedia-Version der Seite.
<% End If %>
Sie können eine Objektinstanz auch im Sitzungsobjekt speichern, dies hat jedoch Auswirkungen auf die Serverleistung.
Verwalten Sie Webfarm-Sitzungen
ASP-Sitzungsinformationen werden auf dem Webserver gespeichert. Der Browser muss eine Seite vom Webserver anfordern, um das Skript zu erhalten, das für den Zugriff auf Sitzungsinformationen verwendet wird. In einer Webfarm (in der sich viele Webserver die Verantwortung für die Beantwortung von Benutzeranfragen teilen) werden Benutzeranfragen nicht immer an denselben Server, sondern durch eine spezielle Software namens „Lastausgleichsprozess“ der Website-Anwendung weitergeleitet ist jedem freien Server zugeordnet. Der Lastausgleichsprozess macht es schwieriger, Sitzungsinformationen in Web Farm beizubehalten.
Um die ASP-Sitzungsverwaltung auf einer Site mit Lastausgleich zu verwenden, müssen Sie sicherstellen, dass alle Anforderungen für eine Benutzersitzung an denselben Webserver weitergeleitet werden. Ein Ansatz besteht darin, eine Session_OnStart-Prozedur zu schreiben, die ein Response-Objekt verwendet, um den Browser an den Webserver umzuleiten, auf dem die Sitzung des Benutzers ausgeführt wird. Wenn alle Links auf Ihren Anwendungsseiten relativ sind, werden alle zukünftigen Anfragen für eine Seite an denselben Server weitergeleitet.
Beispielsweise möchte ein Benutzer auf eine Anwendung zugreifen, indem er die universelle URL einer Website anfordert: http://www.microsoft.com. Der Lastausgleichsprozess leitet Anforderungen an den Server server3.microsoft.com weiter. ASP hat auf diesem Server eine neue Benutzersitzung generiert. Während des Session_OnStart-Prozesses wird der Browser auf den angegebenen Server umgeleitet:
<% Response.Redirect("http://server3.microsoft.com/webapps/firstpage.asp") %>
Der Browser fordert die angegebene Seite an und alle zukünftigen Anfragen werden an denselben Server weitergeleitet.
Verwenden Sie Cookies
Ein Cookie ist ein Token, das der Webserver in den Webbrowser des Benutzers einbettet, um den Benutzer darzustellen. Wenn derselbe Browser das nächste Mal eine Seite anfordert, sendet er das vom Webserver empfangene Cookie. Ein Cookie ermöglicht die Zuordnung einer Reihe von Informationen zu einem Benutzer. ASP-Skripte verwenden die Cookies-Sammlung von Response- und Request-Objekten, um Cookie-Werte abzurufen und festzulegen.
Cookies setzen
Um den Wert eines Cookies festzulegen, verwenden Sie Response.Cookies. Wenn das Cookie nicht vorhanden ist, erstellt Response.Cookies ein neues Cookie. Um beispielsweise einen Cookie-Namen („Planet“) mit einem zugehörigen Wert („Mars“) an den Browser zu senden, verwenden Sie die folgenden Befehle, die vor dem <HTML>-Tag Ihrer Webseite stehen müssen:
<% Response.Cookies("planet")="Mars" %>
Wenn Sie möchten, dass das Cookie nur während der aktuellen Benutzersitzung verwendet wird, senden Sie das Cookie einfach an den Browser. Wenn Sie den Nutzer jedoch auch nach Beendigung oder Neustart des Browsers wiedererkennen möchten, müssen Sie den Browser zwingen, das Cookie auf der Festplatte des Computers zu speichern. Um ein Cookie zu speichern, verwenden Sie die Expires-Eigenschaft von Response.Cookies und legen Sie das Datum auf einen Tag in der Zukunft fest:
<%
Response.Cookies("planet") = "Mars"
Response.Cookies("planet").Expires = "1. Januar 1999"
%>
Ein Cookie kann mehrere Werte haben; ein solches Cookie wird als indiziertes Cookie bezeichnet. Jedem Cookie-Wert ist ein Schlüsselwort zugewiesen. Sie können den Wert eines bestimmten Cookie-Schlüsselworts festlegen. Zum Beispiel:
<% Response.Cookies("planet")("Mars")="SpaceMissions" %>
Wenn ein vorhandenes Cookie einen Schlüsselwortwert hat, Response.Cookies jedoch nicht den Namen eines Schlüsselworts angibt, wird der Schlüsselwortwert gelöscht. Wenn ein vorhandenes Cookie keinen Schlüsselwortwert hat, Response.Cookies jedoch den Namen und den Wert des Schlüsselworts angibt, wird der vorhandene Cookie-Wert gelöscht und ein neues Schlüssel-Wert-Paar generiert.
Holen Sie sich Kekse
Um den Wert eines Cookies zu ermitteln, verwenden Sie die Request.Cookies-Sammlung. Wenn die HTTP-Anfrage des Benutzers beispielsweise „planet=Mars“ festlegt, erhält die folgende Anweisung den Wert „Mars“:
<%= Request.Cookies("planet") %>
Um einen Schlüsselwortwert aus einem indizierten Cookie zu erhalten, verwenden Sie auf ähnliche Weise den Schlüsselwortnamen. Wenn der Benutzer beispielsweise die folgende HTTP-Anfrage stellt:
planet=Mars&Mars=Weltraummissionen
Das folgende Skript gibt den Wert SpaceMissions zurück:
<%= Request.Cookies("planet")("Mars") %>
Einstellen des Cookie-Pfads Jedes von ASP im Webbrowser des Benutzers gespeicherte Cookie enthält Pfadinformationen. Wenn der Browser eine Datei anfordert, deren Speicherort mit dem im Cookie angegebenen Pfad übereinstimmt, leitet der Browser das Cookie automatisch an den Server weiter. Standardmäßig entspricht der Cookie-Pfad dem Anwendungsnamen, der die ASP-Datei enthält, die das Cookie ursprünglich generiert hat. Wenn beispielsweise eine .asp-Datei in einer Anwendung namens UserApplication ein Cookie generiert, wird jedes Mal, wenn der Webbrowser des Benutzers die Datei in dieser Anwendung abruft, der Browser Dieses Cookie wird auch an den Server weitergeleitet.
Um einen Pfad für ein Cookie zu deklarieren, der sich vom Standardanwendungspfad unterscheidet, verwenden Sie die Path-Eigenschaft der Response.Cookies-Sammlung von ASP. Das folgende Skript weist beispielsweise den Pfad SalesApp/Customer/Profiles/ einem Cookie namens Purchases zu:
<%
Response.Cookies("Purchases") = "12"
Response.Cookies("Purchases").Expires = "1. Januar 2001"
Response.Cookies("Purchases").Path = "/SalesApp/Customer/Profiles/"
%>
Immer wenn ein Webbrowser, der das Purchases-Cookie enthält, eine Datei anfordert, die sich im Pfad /SalesApp/Customer/Profiles/ oder seinen Unterverzeichnissen befindet, leitet der Browser das Cookie an den Server weiter.
Viele Webbrowser, einschließlich Microsoft Internet Explorer 4.0 und Netscape-Browser, behalten die Groß-/Kleinschreibung von Cookie-Pfaden bei. Das heißt, wenn die Groß-/Kleinschreibung einer angeforderten Datei vom reservierten Cookie-Pfad abweicht, leitet der Browser das Cookie nicht an den Server weiter. Beispielsweise sind für ASP die virtuellen Verzeichnisse /TRAVEL und /travel dieselbe ASP-Anwendung, für Browser, die die Groß-/Kleinschreibung der URL beibehalten, sind /TRAVEL und /travel jedoch zwei verschiedene Anwendungen. Sie sollten sicherstellen, dass alle URLs zur .asp-Datei die gleiche Groß-/Kleinschreibung haben, um sicherzustellen, dass der Browser des Benutzers das gespeicherte Cookie weiterleiten kann.
Bei Bedarf können Sie mit der folgenden Anweisung den Cookie-Pfad so festlegen, dass das Cookie immer dann weitergeleitet wird, wenn der Webbrowser des Benutzers eine Datei von Ihrem Server anfordert, unabhängig von der Anwendung oder dem Pfad:
Response.Cookies("Purchases").Path = "/"
Bitte beachten Sie jedoch, dass das Senden von Cookies an den Server ohne Unterscheidung zwischen Anwendungen zu Sicherheitsproblemen führen kann, wenn das Cookie vertrauliche Informationen enthält, auf die andere Programme als die vorgesehene Anwendung nicht zugreifen dürfen.
Statuserhaltung ohne Verwendung von Cookies Nicht alle Browser unterstützen Cookies. Selbst wenn Sie einen Browser verwenden, der Cookies unterstützt, ziehen es einige Benutzer möglicherweise vor, die Cookie-Unterstützung zu deaktivieren. Wenn Ihre Anwendung auf Browser reagieren muss, die keine Cookies unterstützen, müssen Sie die ASP-Sitzungsverwaltung verwenden.
Wenn Sie die ASP-Sitzungsverwaltung nicht verwenden, müssen Sie Ihren eigenen Mechanismus schreiben, um Informationen zwischen Ihren Anwendungsseiten weiterzugeben. Es gibt zwei allgemeine Möglichkeiten, diese Aufgabe zu erfüllen:
Fügen Sie der Abfragezeichenfolge der URL Parameter hinzu. Zum Beispiel:
http://MyServer/MyApp/start.asp?name=Jeff
Einige Browser verwerfen jedoch explizite Parameter, die in der Abfragezeichenfolge übergeben werden, wenn das Formular mit der GET-Methode übermittelt wird.
Fügen Sie der Tabelle versteckte Werte hinzu. Die folgende HTML-Tabelle enthält beispielsweise ein implizites Steuerelement. Dieses Steuerelement erscheint nicht in der tatsächlichen Form und ist für den Webbrowser des Benutzers nicht sichtbar. Über die HTTP-POST-Methode übergibt das Formular zusätzlich zu den vom Benutzer bereitgestellten Informationen auch die Benutzer-ID.
<FORM METHOD="POST" ACTION="/scripts/inform.asp">
<INPUT TYPE="text" NAME="city" VALUE="">
<INPUT TYPE="text" NAME="country" VALUE="">
<INPUT TYPE="hidden" NAME="userid" VALUE= <%=UserIDNum(i) %>
<INPUT TYPE="submit" VALUE="Enter">
Diese Methode erfordert, dass alle Linkziele, die Benutzerinformationen übertragen, als HTML-Tabellen kodiert sind.
Wenn Sie derzeit keine ASP-Sitzungsverwaltung verwenden, deaktivieren Sie die Sitzungsunterstützung für Ihre Anwendung. Wenn eine Sitzung aktiviert ist, sendet ASP das SessionID-Cookie an jeden Browser, der eine ASP-Seite anfordert. Um die Sitzungsunterstützung zu deaktivieren, deaktivieren Sie das Kontrollkästchen „Sitzungsstatus aktivieren“ auf der Eigenschaftenseite „Anwendungsoptionen“ im Internet Services Manager.
Sitzungslose ASP-Seite
ASP bietet auch die Möglichkeit, sitzungslose Seiten zu erstellen, mit denen Sie die Sitzungserstellung verschieben können, bis der Benutzer auf eine ASP-Seite zugreift, die eine Sitzungsverfolgung erfordert.
Sitzungslose Seiten führen die folgenden Funktionen nicht aus:
Führen Sie die Session_OnStart-Prozedur aus.
Sitzungs-ID-Cookie senden.
Sitzungsobjekt erstellen.
Greifen Sie auf integrierte Sitzungsobjekte oder sitzungsbezogene Objekte zu, die mit dem <OBJECT>-Tag erstellt wurden.
Wird nacheinander mit anderen Sitzungsanforderungen ausgeführt.
Um .asp sitzungslos zu konfigurieren, verwenden Sie die folgende Anweisung:
<%@ EnableSessionState=False %>
Sie sollten dieses Skript in der ersten Zeile der ASP-Datei vor anderen Skripten platzieren. Wenn dieses Flag weggelassen wird, ist die Sitzungsverfolgung standardmäßig aktiviert.
Sitzungslose ASP-Seiten verbessern die Antwortleistung des Servers, indem sie potenziell zeitaufwändige Sitzungsvorgänge eliminieren. Stellen Sie sich beispielsweise die folgende Situation vor: Eine ASP-Seite enthält zwei HTML-Frames, Frame 1 und Frame 2, in einem Frame-Set. Frame 1 enthält eine ASP-Datei, die ein komplexes Skript ausführt, während Frame 2 eine einfache HTML-Datei enthält. Da ASP Sitzungsanforderungen sequentiell (also seriell) ausführt, sehen Sie den Inhalt von Frame 2 erst, wenn das Skript für Frame 1 ausgeführt wird. Wenn Sie Frame 1 jedoch auf „sitzungslos“ setzen, wird die ASP-Anfrage nicht mehr seriell verarbeitet und der Browser muss nicht warten, bis die Ausführung des Inhalts von Frame 1 abgeschlossen ist, bevor er den Inhalt von Frame 2 verarbeiten kann.
Wie mit mehreren Anfragen für unterschiedliche Frames umgegangen wird, hängt jedoch letztendlich von der Konfiguration des Webbrowsers des Benutzers ab. Einige Webbrowser ignorieren möglicherweise die sitzungslose Konfiguration Ihrer ASP-Datei und verarbeiten Anfragen weiterhin seriell.
