Probleme mit HTTP-Sitzungen
Dieser Artikel enthält Fehlerbehebungsinformationen zum Erstellen oder Verwenden von HTTP-Sitzungen (Hypertext Transfer Protocol).
Verwenden Sie die Administrationskonsole, um die hier beschriebenen Einstellungen des Sitzungsmanagers anzuzeigen und zu aktualisieren. Wählen Sie den Anwendungsserver aus, in dem die fehlerhafte Anwendung ausgeführt wird, und wählen Sie dann unter "Weitere Eigenschaften" zuerst Web-Container und dann Sitzungsmanager aus.
- HTTP-Sitzungen werden nicht erstellt oder gehen zwischen Anforderungen verloren
- HTTP-Sitzungen sind nicht persistent
- Sitzung wird von mehreren Browsern auf derselben Clientmaschine gemeinsam genutzt
- Sitzung wird nach dem angegebenen Intervall für Sitzungszeitlimit nicht direkt invalidiert
- Unerwünschte Sitzungen werden von JSPs erstellt
Sitzungsdaten für einen bestimmten Client werden von einem anderen Client erkannt
- Benutzer werden nach Ablauf des Zeitgebers für HTTP-Sitzungen nicht abgemeldet
- Beim Aktualisieren von Anwendungen mit aktivierter Sitzungspersistenz können zur Laufzeit Ausnahmen eintreten
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
- Lesen Sie im Artikel Tipps zur Fehlerbehebung beim HTTP-Sitzungsmanager die allgemeinen Hinweise zum Debugging von Fehlern, die sich auf den Sitzungsmanager beziehen.
Im Artikel Taskübersicht: HTTP-Sitzungen verwalten finden Sie Informationen zum Konfigurieren des Sitzungsmanagers und empfohlene Methoden zur Verwendung desselben.
- Prüfen Sie, ob der Fehler bekannt ist und dokumentiert wurde. Lesen Sie dazu die entsprechenden Informationen in der verfügbaren Onlineunterstützung (Hinweise und Tipps, technische Anmerkungen und Fixes).
- Wenn Ihr Fehler hier nicht aufgeführt ist, wenden Sie sich an den IBM Support.
HTTP-Sitzungen werden nicht erstellt oder gehen zwischen Anforderungen verloren
- Vergewissern Sie sich, dass das Kontrollkästchen Cookies aktivieren auf der Eigenschaftenseite "Verfahren der Sitzungsüberwachung" aktiviert ist.
- Vergewissern Sie sich, dass auf dem Browser, mit dem Sie testen bzw. mit dem Benutzer auf die Anwendung zugreifen, Cookies aktiviert sind.
- Überprüfen Sie die in SessionManager angegebene Cookiedomäne.
Zum Anzeigen bzw. Aktualisieren der Cookieeinstellungen klicken Sie unter
Ändern.
- Wenn die Cookie-Domäne z. B. mit ".myCom.com" angegeben ist, müssen Sie über denselben Domänennamen auf Ressourcen zugreifen. Beispiel: http://www.myCom.com/myapp/servlet/sessionservlet.
- Wenn die Domäneneigenschaft angegeben ist, vergewissern Sie sich, dass sie mit einem Punkt beginnt (.). Bestimmte
Netscape-Versionen akzeptieren keine Cookies, wenn der Domänenname nicht mit
einem Punkt beginnt. Internet Explorer akzeptiert die Domäne mit oder ohne Punkt. Wenn der Domänenname z. B. mit mycom.com angegeben ist, ändern Sie ihn in .mycom.com, damit Netscape und Internet Explorer das Cookie akzeptieren.Anmerkung: Wenn sich die Server auf unterschiedlichen Hosts befinden, müssen Sie sicherstellen, dass Sitzungscookies an alle Server verteilt werden. Konfigurieren Sie dazu einen Front-End-Router, z. B. einen Web-Server mit Plug-in, oder definieren Sie die Cookiedomäne.
auf - Überprüfen Sie den in SessionManager angegebenen Cookiepfad. Vergewissern Sie sich, dass der fehlerhafte URL in der Hierarchie unter dem angegebenen Cookiepfad angegeben ist. Ist das nicht der Fall, korrigieren Sie den Cookiepfad.
- Ist die Eigenschaft Maximale Lebensdauer des Cookie definiert, vergewissern Sie sich, dass die Datums-/Zeitangabe der Clientmaschine (Browser) einschließlich der Zeitzone mit den entsprechenden Angaben des Servers übereinstimmt. Wenn die Zeitdifferenz zwischen Client und Server über der maximalen Lebensdauer des Cookie liegt, bedeutet jeder Zugriff eine neue Sitzung, da die Lebensdauer des Cookie nach dem Zugriff abgelaufen ist.
- Wenn Sie in einer Unternehmensanwendung mehrere Webmodule haben, die Sitzungen überwachen, gehen Sie wie folgt vor:
- Wenn Sie in einer Unternehmensanwendung andere Sitzungseinstellungen für Webmodule verwenden möchten, vergewissern Sie sich, dass jedes Webmodul einen anderen Cookienamen oder Pfad angibt. Oder:
- Wenn Webmodule in einer Unternehmensanwendung einen allgemeinen Cookienamen und Pfad verwenden, vergewissern Sie sich, dass die Einstellungen der HTTP-Sitzung, wie z. B. die maximale Lebensdauer des Cookie, für alle Webmodule identisch sind. Andernfalls ist das Verhalten der Cookies unvorhersehbar und von der Anwendung, die die Sitzung erstellt, abhängig. Beachten Sie, dass die Sitzungsdaten nicht von den Cookie-Einstellungen abhängig sind, da sie separat vom Webmodul verwaltet werden.
- Überprüfen Sie den Ablauf der Cookies zwischen Browser und Server:
- Aktivieren Sie im Browser die Cookieanfragen. Rufen Sie das Servlet auf, und vergewissern Sie sich, dass das Cookie angefordert wird.
Aktivieren Sie auf dem Server den Trace für den Sitzungsmanager. Aktivieren Sie den Trace für den HTTP-Session-Manager mit der Tracespezifikation "com.ibm.ws.session.*=all=enabled". Aktivieren Sie den Trace, und führen Sie Ihre Sitzung mit dem Servlet oder der JSP aus. Führen Sie dann die genannten Schritte durch, um für die Traceausgabe einen Speicherauszug zu erstellen und die Ausgabe zu durchsuchen.
- Greifen Sie mit dem Browser auf das Sitzungsservlet zu.
- Der Browser fordert das Cookie an, notieren Sie daher die jsessionid.
- Laden Sie das Servlet erneut, und notieren Sie das Cookie, wenn ein neues Cookie gesendet wird.
- Überprüfen Sie den Sitzungstrace, suchen Sie nach der Sitzungs-ID, und führen Sie für die Anforderung ein Tracing nach Thread durch. Prüfen
Sie, ob die Sitzung in den verschiedenen Webanforderungen stabil ist:
- Suchen Sie nach "getIHttpsession(...)", um den Anfang der Sitzungsanforderung zu ermitteln.
- Suchen Sie nach "releaseSession(..)", um das Ende der Sitzungsanforderung zu ermitteln.
- Wenn Sie das Umschreiben von URLs anstelle von Cookies verwenden, gehen Sie wie folgt vor:
- Vergewissern Sie sich, dass keine statischen HTML-Seiten im Navigationspfad der Anwendung angegeben sind.
Vergewissern Sie sich, dass die Servlets und JSP-Dateien das Umschreiben von URLs ordnungsgemäß implementieren. Details und Beispiele finden Sie im Artikel Optionen für die Sitzungsüberwachung.
- Wenn Sie SSL als Verfahren der Sitzungsüberwachung verwenden, gehen Sie wie folgt vor:
Veraltetes Feature: Die Sitzungsüberwachung mithilfe der SSL-ID ist seit WebSphere Application Server Version 7.0 veraltet. Sie können die Sitzungsüberwachung für die Verwendung von Cookies konfigurieren oder die Anwendung für die Verwendung der URL-Umschreibung ändern.depfeat
- Vergewissern Sie sich, dass in IBM HTTP Server oder im HTTP-Server iPlanet SSL aktiviert ist.
Lesen Sie den Artikel Optionen für die Sitzungsüberwachung.
- Wenn Sie in einer Clusterumgebung (mehrere Knoten) arbeiten, stellen Sie sicher, dass die Sitzungspersistenz aktiviert ist.
HTTP-Sitzungen sind nicht persistent
- Überprüfen Sie die Datenquelle.
- Überprüfen Sie die Persistenzeigenschaften des Sitzungsmanagers:
- Falls Sie die Sitzungspersistenz nutzen möchten, muss die Eigenschaft "Persistenz" auf Datenbank gesetzt sein.
Die Eigenschaft "Persistenz" kann auch auf Replikation zwischen Speichern gesetzt werden.
- Wenn Sie die datenbankbasierte Persistenz verwenden, gehen Sie wie folgt vor:
- Überprüfen Sie den JNDI-Namen der Datenquelle, die im Sitzungsmanager richtig angegeben sein muss.
- Geben Sie die richtige Benutzer-ID und das richtige Kennwort für den Zugriff auf die Datenbank an.
Beachten Sie, dass diese Einstellungen gegen die Eigenschaften einer vorhandenen Datenquelle in der Administrationskonsole geprüft werden müssen. Der Sitzungsmanager erstellt nicht automatisch eine Sitzungsdatenbank.
- Die Datenquelle darf keine JTA-Datenquelle sein und darf nicht XA-fähig sein.
Suchen Sie in den JVM-Protokollen nach Fehlernachrichten zur Datenbank.
Suchen Sie in den Protokollen nach Fehlernachrichten zur Datenbank.
- Wenn Sie für DB2 andere Zeilengrößen als 4 KB verwenden möchten, müssen Sie sicherstellen, dass die Zeilengröße der DB2-Seitengröße entspricht. Vergewissern Sie sich, dass der Name des Tabellenbereichs richtig angegeben ist.
- Geben Sie wie folgt vor, wenn Sie speicherbasierte Persistenz verwenden (gilt nur für
Network-Deployment-Umgebungen):
- Informationen hierzu finden Sie im Artikel Replikation zwischen Speichern. .
- Überprüfen Sie die Eigenschaften für interne Replikationsdomänen Ihres Sitzungsmanagers.
Sitzung wird von mehreren Browsern auf derselben Clientmaschine gemeinsam genutzt
Dieses Verhalten ist vom Browser abhängig. Es variiert je nach Browsermarke und kann auch davon abhängen, ob ein Browser als neuer Prozess oder als Unterprozess einer vorhandenen Browsersitzung gestartet wird (z. B. durch Drücken der Tastenkombination Strg+N unter Windows).
Die Eigenschaft "Maximale Lebensdauer des Cookie" des Sitzungsmanagers wirkt sich ebenfalls auf dieses Verhalten aus, wenn Cookies als Verfahren der Sitzungsüberwachung verwendet werden. Wird für die maximale Lebensdauer ein positiver Wert festgelegt, verwenden alle Browser-Instanzen die Cookies, die in einer Datei auf dem Client für die angegebene maximale Lebensdauer persistent gespeichert sind.
Sitzung wird nach dem angegebenen Intervall für Sitzungszeitlimit nicht direkt invalidiert
Der Prozessthread des Sitzungsmanagers für die Invalidierung wird alle x Sekunden ausgeführt, um alle ungültigen Sitzungen zu invalidieren. "x" wird auf der Basis des Intervalls für das Sitzungszeitlimit, das in den Eigenschaften des Sitzungsmanagers angegeben ist, bestimmt. Für den Standardwert von 30 Minuten beträgt x etwa 300 Sekunden. In diesem Fall dauert es maximal 5 Minuten (300 Sekunden) über das Zeitlimit von 30 Minuten hinaus, bis eine bestimmte Sitzung invalidiert wird.
Unerwünschte Sitzungen werden von JSPs erstellt
<% @page session="false" %>
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Sitzungsdaten für einen bestimmten Client werden von einem anderen Client erkannt
In seltenen Fällen können Sitzungsdaten, die für einen bestimmten Client vorgesehen sind, von einem anderen Client erkannt werden. In einer solchen Situation spricht man von vertauschten Sitzungsdaten. Wenn die angepasste Eigenschaft "DebugSessionCrossover" auf "true" gesetzt ist, wird Code zur Ermittlung von Protokollierung von Instanzen vertauschter Sitzungsdaten aktiviert. Es wird sichergestellt, dass nur auf die Sitzung, die der Anforderung zugeordnet ist, zugegriffen wird. Außerdem wird sichergestellt, dass nur diese Sitzung referenziert wird. Wenn Diskrepanzen ermittelt werden, werden Nachrichten protokolliert. Diese Nachrichten bieten einen Ausgangspunkt für das Debugging dieses Fehlers. Diese zusätzliche Prüfung wird nur durchgeführt, wenn der Betrieb mit dem von WebSphere verwalteten Zuteilungsthread und nicht mit von Benutzern erstellten Threads erfolgt.
Zusätzliche Informationen zum Setzen dieser Eigenschaft enthält der Artikel Angepasste Eigenschaften des Web-Containers.
Benutzer werden nach Ablauf des Zeitgebers für HTTP-Sitzungen nicht abgemeldet
Wenn Benutzer von WebSphere Application Server sich bei einer Anwendung anmelden und einen längeren Zeitraum inaktiv sind als durch das Zeitlimit für HTTP-Sitzungen angegeben, werden die Benutzerdaten nicht invalidiert, und die Benutzerberechtigung bleibt aktiv, bis das Zeitlimit für LTPA-Token überschritten wird.
- Klicken Sie in der Administrationskonsole auf Sicherheit > Globale Sicherheit.
- Klicken Sie auf der Seite "Angepasste Eigenschaften" auf Neu.
- Geben Sie im Feld "Name" die Eigenschaft "com.ibm.ws.security.web.logoutOnHTTPSessionExpire" ein.
- Im Feld "Wert" geben Sie "true" ein.
- Klicken Sie auf "Anwenden", und speichern Sie die Änderungen dann in Ihrer Masterkonfiguration.
- Resynchronisieren Sie den Server und starten Sie den Server neu.
Beim Aktualisieren von Anwendungen mit aktivierter Sitzungspersistenz können zur Laufzeit Ausnahmen eintreten
Benutzer, die die Sitzungspersistenz aktiviert haben und Anwendungsaktualisierungen zur Laufzeit durchführen, können nach dem Neustart der Anwendung unerwartete Ausnahmen empfangen.
Wenn Aktualisierungen vorgenommen wurden, die die gespeicherten Attribute ändern, müssen möglicherweise alle Sitzungen, die von der zugehörigen Anwendung erstellt wurden, vor der Anwendungsaktualisierung ungültig gemacht werden, falls die Anwendung diese Änderungen nicht verarbeiten kann. In diesem Fall müssen alle Sitzungsobjekte auch vom Back-End entfernt werden. Weitere Einzelheiten zum ordnungsgemäßen Entfernen dieser Sitzungen finden Sie in den Informationen zur Invalidierung von HTTP-Sitzungen.