web-dev-qa-db-fra.com

La session est perdue et créée comme nouvelle dans chaque demande de servlet

J'ai ce gros problème. Ma session en cours disparaît chaque fois que je fais une nouvelle demande au serveur.

J'ai vérifié dans beaucoup d'endroits. Je ne trouve pas quel est le problème. J'ai également inclus session-config dans web.xml à la fois dans Tomcat et dans l'application. J'ai également permis d'accepter les cookies de mes navigateurs. Testé dans tous les navigateurs. Ça ne fonctionne pas.

Je suis en train de développer un simple Java ee applcation utilisant JSP/Servlet. Je ne fais face au problème qu'après avoir déployé sur Tomcat sur une machine serveur.

javasessiontomcatservlets
35
Min Soe

Après des années, je n'ai jamais posté la réponse ici. A cette époque, j'étais occupé et j'ai oublié cette question. Mais, aujourd'hui, je cherche une solution dans Stackoverflow comme d'habitude et j'ai vu cette notification mentionnant que j'obtiens des points de cette question. Il semble que d'autres développeurs soient confrontés au même problème. J'ai donc essayé de me rappeler comment j'ai résolu le problème. Et oui, j'ai résolu en remettant manuellement l'ID de session pour suivre/maintenir l'ID de session.

Veuillez voir le code que j'ai remis manuellement jsessionid à l'intérieur du servlet.

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);
}
22
Min Soe

Une cause possible à cela est d'avoir un nom d'hôte "nu" (c'est-à-dire un sans partie de domaine). C'est assez courant si vous travaillez dans un intranet.

Le problème est que presque tous les cookies des navigateurs n'acceptent pas les cookies pour les noms d'hôtes sans nom de domaine. Cela est fait pour empêcher evilsite.com de définir un cookie pour com (ce qui serait mauvais, car ce serait le cookie de suivi ultime).

Donc, si vous accédez à votre application via http://examplehost/ il n'acceptera aucun cookie, tandis que pour http://examplehost.localdomain/ il acceptera (et retournera) le cookie très bien.

La chose désagréable à ce sujet est que le serveur ne peut pas faire la distinction entre "le navigateur a obtenu le cookie et l'a ignoré" et "le navigateur n'a jamais obtenu le cookie". Ainsi, chaque accès unique ressemblera à une session entièrement nouvelle sur le serveur.

39
Joachim Sauer

Vérifiez d'abord si la context.xml de la webapp n'est pas cookies="false" Configurée.

De plus, il est bon de savoir que les cookies dépendent du domaine, du port et du chemin de contexte. Si les liens de la page pointent vers un domaine, un port et/ou un chemin de contexte différent par opposition à l'URL de demande actuelle (celle que vous voyez dans la barre d'adresse du navigateur), le cookie a gagné ' t être passé à travers ce qui fera que la session ne pourra plus être identifiée et donc vous en obtiendrez une nouvelle du servletcontainer.

Si ce n'est pas la cause, vérifiez si vous n'effectuez pas de redirection sur chaque demande en utilisant HttpServletResponse.sendRedirect() pour une raison quelconque. Si vous le faites déjà à la toute première demande, le cookie sera perdu. Vous devrez remplacer

response.sendRedirect(url);

par

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

J'ai rencontré un cookie de session https périmé (mon terme ad-hoc), en raison d'un indicateur sécurisé.

J'ai eu ce problème lors du basculement entre http et https. Le cookie stocké par la session https n'a jamais été remplacé par la session http. Il est resté dans la mémoire de FireFox pour l'éternité. Il était visible dans FireFox Outils/Options/Confidentialité/Supprimer les cookies uniques où dans Envoyer pour champ c'était Uniquement pour les connexions sécurisées. La suppression de ce cookie unique ou de tous les cookies est une solution de contournement.

Je déboguais le problème avec wget, et j'ai remarqué un tel en-tête:

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

Le mot sécurisé n'apparaît que dans les connexions https et crée ce cookie périmé. C'est un SecureFlag (voir OWASP ). Il existe des moyens de désactiver cet indicateur côté serveur, ce qui semble être une solution permanente, mais peut-être pas sûr.

Ou est-ce un bug du navigateur, que le cookie n'est pas écrasé?

3
Jarekczek

Essayez d'ajouter le plug-in Live Http Headers à firefox, et assurez-vous que le cookie de session est bien transmis au navigateur depuis le serveur, et assurez-vous que le navigateur le renvoie à la prochaine demande.

3
skaffman

Veuillez vérifier si la session n'est pas invalidée dans votre code quelque part. Recherchez un code similaire à request.getSession().invalidate();

3
Kees de Kooter

S'il y a une configuration d'équilibrage de charge, il faudra avoir à configurer une route dans le réseau pour conserver les requêtes sur le même serveur. Sinon, chaque demande ira à un serveur différent, perdant l'attribut de session.

1
marcelobrgomes

Modifiez votre Tomcat context.xml fichier et remplacer <Context> tag vers <Context useHttpOnly="false">, cela m'a aidé.

1
Benas

Dans vos propriétés

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

Supprimez ces paramètres, il conservera votre cookie d'ID de session, qui est réinitialisé à chaque demande.

1
LNT