Dans quelles conditions un JSESSIONID est-il créé?
quand / quelles sont les conditions de création d'un JSESSIONID ?
est-ce par domaine? Par exemple, si j'ai un serveur D'applications Tomcat, et que je déploie plusieurs applications web, est-ce qu'un JSESSIONID différent sera créé par contexte (application web), ou est-il partagé entre les applications web aussi longtemps qu'ils sont le même domaine?
5 réponses
JSESSIONID est créé / envoyé lorsque la session est créée. La Session est créée lorsque votre code appelle request.getSession() ou request.getSession(true) pour la première fois. Si vous voulez juste obtenir la session, mais pas la créer si elle n'existe pas, utilisez request.getSession(false) -- cela vous retournera une session ou null . Dans ce cas, la nouvelle session n'est pas créée, et le cookie JSESSIONID n'est pas envoyé. (Cela signifie également que la session n'est pas nécessairement créée à la première demande ... vous et votre code est dans le contrôle quand la session est créée)
Sessions sont par-contexte:
SRV.7.3 Domaine D'Application De La Session
Les objetsHttpSession doivent être scopés à l'application (ou le contexte de servlet)) niveau. Le mécanisme sous-jacent, tels le cookie utilisé pour établir la session, peut être le même pour différents contextes, mais l'objet référencé, y compris les attributs dans que objet, ne doit jamais être partagé entre contextes par le conteneur.
mise à jour: chaque appel à la page JSP crée implicitement une nouvelle session s'il n'y a pas encore de session. Cela peut être désactivé avec la directive page session='false' , auquel cas la variable session n'est pas disponible sur la page JSP.
voici quelques informations sur une autre source du cookie JSESSIONID :
j'étais en train de déboguer du code Java qui tourne sur un serveur tomcat. Je n'appelais pas request.getSession() explicitement n'importe où dans mon code mais j'ai remarqué qu'un cookie JSESSIONID était encore en cours de paramétrage.
j'ai finalement regardé le code Java généré correspondant à un JSP dans le répertoire de travail sous Tomcat.
il apparaît que, si vous l'aimez ou pas, si vous invoquez un JSP à partir d'un servlet, JSESSIONID sera créé!
ajouté: je viens de constater qu'en ajoutant la directive JSP suivante:
<%@ page session="false" %>
vous pouvez désactiver le réglage de JSESSIONID par un JSP.
CORRECTION: veuillez voter pour la réponse de Peter Štibraný - elle est plus correcte et complète!
UN "JSESSIONID" est l'id unique de la session http - voir la javadoc ici . Dans le javadoc, vous trouverez la phrase suivante: "les informations de Session sont scopées uniquement vers L'application Web actuelle (ServletContext), de sorte que les informations stockées dans un contexte ne seront pas directement visibles dans un autre."
donc quand vous frappez pour la première fois un site, une nouvelle session est créée et liée au SevletContext. Si vous déployez plusieurs applications, la session n'est pas partagé.
vous pouvez également invalider la session en cours et en créer une nouvelle. par exemple, lors du passage de http à https (après connexion), c'est une très bonne idée de créer une nouvelle session.
Hope, ceci répond à votre question.
attention si votre page inclut autre .jsp ou .JSPF (fragment)! Si vous ne mettez pas
<%@ page session="false" %>
sur eux aussi, la page mère va finir par démarrer une nouvelle session et configurer le cookie JSESSIONID.
For .pages jspf en particulier, cela se produit si vous avez configuré votre web.xml avec un extrait de:
<jsp-config>
<jsp-property-group>
<url-pattern>*.jspf</url-pattern>
</jsp-property-group>
</jsp-config>
afin d'activer les scriptlets à l'intérieur d'eux.
pour les liens générés dans un JSP avec des étiquettes personnalisées, j'ai dû utiliser
<%@ page session="false" %>
dans le JSP
et
request.getSession().invalidate();
dans les jambes de force de l'action