Dans quelles conditions un JSESSIONID est-il créé ?

Question

Quand / quelles sont les conditions dans lesquelles un JSESSIONID est créé ?

Est-il par un domaine ? Par exemple, si j'ai un serveur d'applications Tomcat et que je déploie plusieurs applications Web, est-ce qu'un serveur d'applications différent sera utilisé pour chaque domaine ? JSESSIONID être créé par contexte (application web), ou est-il partagé entre les applications web tant qu'elles appartiennent au même domaine ?

Answer 1

Le cookie JSESSIONID est créé/envoyé lors de la création de la session. La session est créée lorsque votre code appelle request.getSession() o request.getSession(true) pour la première fois. Si vous voulez simplement obtenir la session, mais ne pas la créer si elle n'existe pas, utilisez request.getSession(false) -- cela vous renverra une session ou null . Dans ce cas, une 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 sont sous contrôle quand la session est créée)

Les sessions se déroulent en fonction du contexte :

SRV.7.3 Étendue de la session

Les objets HttpSession doivent avoir une portée à l'application (ou le contexte de servlet) d'application (ou contexte de servlet). Le mécanisme sous-jacent, tel que comme 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 y compris les attributs de cet cet objet, ne doit jamais être partagé entre contextes par le conteneur.

( Spécification Servlet 2.4 )

Mise à jour : Chaque appel à une page JSP crée implicitement une nouvelle session s'il n'y en a pas encore. Ceci peut être désactivé avec l'option session='false' Dans ce cas, la variable de session n'est pas du tout disponible sur la page JSP.

Answer 2

Voici quelques informations sur une autre source de la JSESSIONID cookie :

J'étais en train de déboguer un 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'une JSESSIONID Le cookie était encore en cours d'installation.

J'ai finalement jeté un coup d'oeil au code Java généré correspondant à une JSP dans le répertoire de travail sous Tomcat.

Il semble que, que vous le vouliez ou non, si vous invoquez un JSP depuis une servlet, JSESSIONID sera créé !

Ajouté : Je viens de découvrir qu'en ajoutant la directive JSP suivante :

<%@ page session="false" %>

vous pouvez désactiver le réglage de JSESSIONID par une JSP.

Answer 3

CORRECTION : Veuillez voter pour la réponse de Peter Štibraný - elle est plus correcte et complète !

Le "JSESSIONID" est l'identifiant unique de la session http. voir la javadoc ici . Vous y trouverez la phrase suivante

Les informations relatives à la session ne concernent que l'application Web actuelle (ServletContext). Les informations stockées dans un contexte ne seront donc pas directement visibles dans un autre.

Ainsi, lorsque vous visitez un site pour la première fois, une nouvelle session est créée et liée au SevletContext. Si vous déployez plusieurs applications, la session n'est pas partagée.

Vous pouvez également invalider la session actuelle et donc en créer une nouvelle. Par exemple, lorsque vous passez de http à https (après la connexion), c'est une très bonne idée de créer une nouvelle session.

J'espère que cela répond à votre question.

Answer 4

Attention si votre page contient d'autres .jsp ou .jspf (fragment) ! Si vous ne définissez pas

<%@ page session="false" %>

sur eux également, la page mère finira par démarrer une nouvelle session et par définir le cookie JSESSIONID.

Pour les pages .jspf en particulier, cela se produit si vous avez configuré votre web.xml avec un tel extrait :

<jsp-config>
    <jsp-property-group>
        <url-pattern>*.jspf</url-pattern>
    </jsp-property-group>
</jsp-config>

afin d'activer les scriptlets à l'intérieur de ceux-ci.

Answer 5

Pour les liens générés dans une JSP avec des balises personnalisées, j'ai dû utiliser

<%@ page session="false" %>

dans la JSP

ET

request.getSession().invalidate();

dans l'action Struts