Sitzung ist verloren und neu erstellt in jeder Servlet-Anfrage

Question

Ich habe dieses große Problem. Meine aktuelle Sitzung ist jedes Mal beendet, wenn ich eine neue Anfrage an den Server gestellt habe.

Ich habe an vielen Orten eingecheckt. Ich kann nicht finden, was das Problem ist. Ich habe auch session-config in web.xml sowohl in Tomcat und Anwendung. Ich habe auch Cookies in meinem Browser akzeptiert. Getestet in jedem Browser. Es funktioniert nicht.

Ich entwickle gerade eine einfache Java ee Anwendung mit JSP/Servlet. Ich bin mit dem Problem nur konfrontiert, nachdem ich auf Tomcat in Server-Maschine eingesetzt habe.

Answer 1

Nach Jahren habe ich die Antwort nie wieder hier gepostet. Zu dieser Zeit war ich beschäftigt und vergaß diese Frage. Aber heute suche ich wie immer in Stackoverflow nach einer Lösung und sehe in dieser Benachrichtigung, dass ich Punkte von dieser Frage bekomme. Es scheint, als ob andere Entwickler mit dem gleichen Problem konfrontiert sind. Also versuchte ich mich zu erinnern, wie ich das Problem gelöst habe.Und ja, ich habe gelöst, indem ich die Sitzungs-ID manuell zurücksetzte, um die Sitzungs-ID zu verfolgen/zu verwalten.

Bitte beachten Sie den Code, den ich jsessionid manuell in das Servlet zurückstellen.

HttpSession session = request.getSession(); 
if (request.getParameter("JSESSIONID") != null) { 
    Cookie userCookie = new Cookie("JSESSIONID", request.getParameter("JSESSIONID")); 
    response.addCookie(userCookie); 
} else { 
    String sessionId = session.getId(); 
    Cookie userCookie = new Cookie("JSESSIONID", sessionId); 
    response.addCookie(userCookie); 
} 

Answer 2

Versuchen Sie, firefox die Live Http Headers plugin hinzuzufügen, und stellen Sie sicher, dass der Sitzungscookie tatsächlich vom Server an den Browser übergeben wird, und stellen Sie sicher, dass der Browser ihn bei der nächsten Anfrage erneut sendet.

Answer 3

Überprüfen Sie bitte, ob die Sitzung in Ihrem Code nicht ungültig ist. Suchen Sie nach Code ähnlich request.getSession().invalidate();

Answer 4

Prüfen Sie zunächst, ob die Webapp des context.xml tut nicht haben cookies="false" konfiguriert.

Weiterhin ist es gut zu wissen, dass Cookies abhängig von Domain, Port und Contextpath sind. Wenn die Links auf der Seite auf eine andere Domäne, einen Port und/oder einen Kontextpfad im Gegensatz zur aktuellen Anforderungs-URL (die in der Adressleiste des Browsers angezeigt wird) zeigen, wird der Cookie nicht durchgelassen dass die Sitzung nicht mehr identifiziert werden kann und Sie eine neue vom Servletcontainer erhalten.

Wenn das nicht die Ursache ist, dann prüfen Sie, ob Sie nicht eine Umleitung auf jede Anfrage mit HttpServletResponse.sendRedirect() aus irgendeinem Grunde tun. Wenn Sie dies bereits bei der ersten Anfrage tun, geht der Cookie verloren. Sie werden

response.sendRedirect(url); 

von

response.sendRedirect(response.encodeRedirectURL(url)); 

Answer 5

Einer möglichen Ursache für diese einen „nackten“ Hostnamen (d einen ohne Domänenteil) ersetzen müssen. Das ist ziemlich üblich, wenn Sie in einem Intranet arbeiten.

Das Problem ist, dass fast alle Browser-Cookies keine Cookies für Hostnamen ohne Domänennamen akzeptieren. Dies wurde gemacht, um zu verhindern, dass evilsite.com ein Cookie für com setzt (was schlimm wäre, da es das ultimative Tracking-Cookie wäre).

Wenn Sie also über http://examplehost/ auf Ihre Anwendung zugreifen, wird kein Cookie akzeptiert, während für http://examplehost.localdomain/ das Cookie akzeptiert und zurückgegeben wird.

Das Schlechte daran ist, dass der Server nicht unterscheiden kann zwischen "der Browser hat das Cookie bekommen und es ignoriert" und "der Browser hat das Cookie nie bekommen". So wird jeder einzelne Zugriff für den Server wie eine komplett neue Sichtweise aussehen.

Answer 6

Bearbeiten Sie Ihre tomcat context.xml Datei und <Context> Tag <Context useHttpOnly="false"> ersetzen, das hat mir geholfen.

Answer 7

Ich erleben einen abgestanden https Session-Cookie (mein Ad-hoc-term) Problem, aufgrund einer sicheren Flagge.

Ich hatte dieses Problem beim Wechsel zwischen http und https. Der Cookie, der von der https-Sitzung gespeichert wurde, wurde nie von der http-Sitzung überschrieben. Es blieb in FireFox Erinnerung für die Ewigkeit. Es war sichtbar in FireFox Werkzeuge/Optionen/Datenschutz/Löschen Sie einzelne Cookies wo in Senden Sie für Feld war es Nur für sichere Verbindungen. Das Löschen dieses einzelnen Cookies oder aller Cookies ist eine Umgehungslösung.

Ich war das Debuggen, das Problem mit wget, und ich bemerkte einen solchen Header:

Set-Cookie: JSESSIONID=547ddffae0e5c0e2d1d3ef21906f; Path=/myapp; Secure; HttpOnly 

Das Wort sicher dieses abgestandene Cookie nur in https-Verbindungen und erstellt wird angezeigt. Es ist ein SecureFlag (siehe OWASP). Es gibt Möglichkeiten, dieses Flag auf der Serverseite zu deaktivieren, was wie eine dauerhafte Lösung aussieht, aber möglicherweise nicht sicher ist.

Oder ist es ein Browserfehler, dass der Cookie nicht überschrieben wird?

Answer 8

Wenn eine Lastausgleichskonfiguration vorhanden ist, müssen Sie eine Route im Netzwerk konfigurieren, um Anforderungen auf demselben Server zu speichern. Andernfalls wird jede Anforderung an einen anderen Server gesendet, wodurch das Sitzungsattribut verloren geht.

Answer 9

in Ihren Eigenschaften

server.session.cookie.http-only=true 
    server.session.cookie.secure=true 

diese Einstellungen entfernen, wird sie Ihre Session-ID-Cookie, behalten, die mit jeder Anfrage zurückgesetzt zu werden wird.