Je n’y avais pas prêté beaucoup d’attention quand j’étudiais avant, mais aujourd’hui je suis revenu étudier attentivement le cycle de vie de la séance.
Les sessions sont stockées côté serveur, et généralement, afin d’éviter qu’elles ne soient dans la mémoire du serveur (pour un accès rapide), Sessinon crée la première fois que l’utilisateur accède au serveur.Notez que l’accès uniquement à JSP, Servlet et autres programmes créera une Session, et que seuls les accès à des ressources statiques telles que HTML et IMAGE ne créeront pas de Session.
Quand une session expire-t-elle ?
1. Le serveur effacera la session de la mémoire inactive depuis longtemps, et la session sera invalide. Le temps d’expiration par défaut d’une session dans Tomcat est de 20 minutes.
2. Appeler la méthode d’invalidation de la Session.
Exigences de session pour les navigateurs :
Bien que la session soit stockée sur le serveur et transparente pour le client, son fonctionnement normal nécessite toujours le support du navigateur du client. C’est parce que Session doit utiliser des cookies comme identifiant. Le protocole HTTP est sans état, et la session ne peut pas être jugée par la connexion HTTP pour déterminer s’il s’agit du même client, donc le serveur envoie un cookie appelé JSESSIONID au navigateur client, qui contient la valeur de l’id de la session (c’est-à-dire la valeur de retour de HttpSession.getId()). Session utilise le cookie pour identifier s’il s’agit du même utilisateur.
Ce cookie est généré automatiquement par le serveur, et son attribut maxAge est généralement -1, ce qui signifie qu’il n’est valable que dans le navigateur actuel, n’est pas partagé entre les fenêtres du navigateur, et ne sera pas valide lorsque le navigateur est fermé. Ainsi, lorsque deux fenêtres de navigateur sur la même machine accèdent au serveur, deux sessions différentes sont générées. Sauf pour les nouvelles fenêtres ouvertes par des liens, scripts, etc. dans la fenêtre du navigateur (c’est-à-dire pas les fenêtres ouvertes en double-cliquant sur les icônes du navigateur de bureau, etc.). Ces fenêtres enfants partagent le cookie de la fenêtre parent et donc une session.
Note : Les nouvelles sessions sont générées dans les nouvelles fenêtres du navigateur ouvertes, sauf pour les sous-fenêtres. La fenêtre enfant partage la session de la fenêtre parente. Par exemple, lorsque vous faites un clic droit sur un lien et sélectionnez « Ouvrir dans une nouvelle fenêtre » dans le menu raccourci qui s’affiche, la fenêtre enfant peut accéder à la Session de la fenêtre parente.
Que se passe-t-il si le navigateur client désactive les cookies ou ne les prend pas en charge ? Par exemple, la grande majorité des navigateurs mobiles ne prennent pas en charge les cookies. Java Web propose une autre solution : la réécriture des adresses URL.
La réécriture d’adresses URL est une solution pour les clients qui ne prennent pas en charge les cookies. Le principe de la réécriture d’adresses URL consiste à réécrire les informations d’identification de la session de l’utilisateur en adresse URL. Le serveur peut analyser l’URL réécrite pour obtenir l’identifiant de session. De cette façon, même si le client ne prend pas en charge les cookies, la session peut être utilisée pour enregistrer l’état de l’utilisateur. La classe HttpServletResponse fournit encodeURL (URL de chaîne) pour implémenter la réécriture des adresses URL, ce qui détermine automatiquement si le client prend en charge les cookies. Si le client prend en charge les cookies, l’URL sera produite telle quelle. Si le client ne prend pas en charge les cookies, l’identifiant de la session utilisateur est réécrit en URL.
Note : TOMCAT détermine si un navigateur client prend en charge les cookies en fonction de l’inclusion d’un cookie dans la requête. Bien que le client puisse prendre en charge les cookies, puisque aucun cookie n’est transporté lors de la première requête (car il n’existe pas de cookies qui le permettent), l’adresse URL réécrite aura toujours jsessionid dans l’adresse. Le serveur a déjà écrit un cookie dans le navigateur lors de la deuxième visite, donc l’adresse URL réécrite n’aura pas jsessionid dans l’adresse.
|
Publié sur 19/04/2015 19:44:59
|
|
|
Publié sur 18/03/2017 16:52:21