Cet article présente principalement le principe de fonctionnement de la session de servlet. L'éditeur pense que c'est plutôt bon. Maintenant, je vais le partager avec vous et le donner comme référence. Suivons l'éditeur pour y jeter un œil
Pour comprendre le principe de fonctionnement sous-jacent de Session. Examinons d'abord la situation dans laquelle le même navigateur accède à plusieurs ressources Web au cours d'une session. Elle peut être grossièrement divisée en les étapes suivantes :
1 Le navigateur accède à un Servlet , à ce moment-là, si. le serveur veut obtenir l'objet Session à partir de l'objet requête (la première acquisition est également créée), alors le serveur va créer un identifiant pour cet objet Session : JSESSIONID
2, et en même temps , dans le navigateur Pendant le processus de réponse, cette session renverra l'identifiant JSESSIONID au navigateur client sous la forme d'un cookie. N'oubliez pas que le serveur de cookies ne définit pas la durée de validité à ce moment, il est donc stocké dans le navigateur. cache, pas dans le fichier du disque dur.
3. Lorsque l'utilisateur continue d'accéder à d'autres servlets pendant cette session, le servlet obtiendra l'objet Session à partir de l'objet de requête. Notez que l'obtention de l'objet Session à ce moment est une requête envoyée par le. navigateur. Demandez s'il existe un cookie nommé JSESSIONID. S'il existe, la session n'a pas besoin d'être recréée, mais interroge directement la session avec la même valeur JSESSIONID dans le serveur. la session peut être obtenue.
En résumé, Session est basée sur Cookie.
(Remarque : les cookies ne sont pas omnipotents. La session s'appuie d'abord sur les cookies, mais parfois les cookies ne peuvent pas être utilisés. À ce stade, la session vérifiera si l'adresse URL envoyée par la demande a un JSESSIONID.)
Cookies cachés de la session, nous pouvons faire une petite expérience pour le vérifier. Créez deux servlets sous le projet web [myservlet], nommés respectivement SessionDemo1 et SessionDemo2 :
Le le code dans SessionDemo1 est :
HttpSession session = request.getSession(); String data = "Message from SessionDemo"; session.setAttribute("data", data);
Le code dans SessionDemo2 est :
HttpSession session = request.getSession(); System.out.println((String)session.getAttribute("data"));
Nous ouvrons HttpWatch dans le navigateur pour accéder à SessionDemo1 Puisque c'est la première fois que vous accédez au Servlet, vérifiez la réponse de SessionDemo1 au navigateur :
Lorsque vous visitez à nouveau le serveur, le navigateur apportera ce cookie nommé JSESSIONID au serveur. Le serveur utilise la valeur JSESSIONID dans ce cookie pour trouver la session précédemment créée pour le navigateur sur le serveur. .
Si nous fermons le navigateur, puisque ce cookie n'a pas défini "setMaxAge", ce cookie n'existe que dans le tampon du navigateur et sera détruit à la fermeture du navigateur. Si nous voulons que la session existe toujours après la fermeture du navigateur, nous devons écraser manuellement le cookie de session et définir la durée de validité et le chemin effectif du cookie de remplacement.
via la méthode getId() de Session.
. Cela peut être vu dans le fichier [web.xml] de Tomcat :
Bien sûr, nous pouvons également modifier la destruction par défaut du serveur des sessions sans opération à partir d'ici.
Bien entendu, si nous ne souhaitons pas définir globalement le temps de destruction de Session sur tous les serveurs, nous pouvons personnaliser 2154b31975826eec7c9ecbf8f296fb33 chaque application Web.
Remarque : Nous pouvons également détruire une Session immédiatement via la méthode invalidate() de l'objet Session.
À cet égard, si nous souhaitons écraser un cookie de session et l'enregistrer dans un fichier du disque dur, la durée de validité du cookie que nous définissons ne doit pas dépasser le délai d'expiration de session par défaut du serveur.
Si nous créons un objet Cookie et ne définissons pas "setPath", alors le chemin effectif de le cookie consiste à créer le programme du cookie (généralement un servlet), c'est-à-dire que le navigateur emportera le cookie avec lui uniquement lors de l'accès à ce programme qui est vraiment "non connecté", et la session ne peut pas être utilisée pour accéder à d'autres ressources de. cette application Web.
Regardons le chemin effectif du cookie dans la Session créé par le serveur pour le navigateur lorsque nous avons accédé au Servlet pour la première fois :
可以看到这个服务器默认将JSESSIONID这个cookie的有效路径设置为创建这个Session的web工程根目录。所以我们要覆盖Session中的cookie时也应该设置路径为该web工程根目录。
好,接下来对上面那个Servlet的例子进行改造,我们只需要在SessionDemo1中修改就行,因为这个首次将Session的cookie返回给客户端,修改后代码如下:
HttpSession session = request.getSession(); String data = "Message from SessionDemo"; session.setAttribute("data", data); Cookie cookie = new Cookie("JSESSIONID", session.getId()); cookie.setMaxAge(30*60); cookie.setPath("/myservlet"); response.addCookie(cookie);
这样,当我们打开浏览器访问了SessionDemo1之后,就能在存放cookie的目录中找到该cookie,如果我们通过HttpWatch来查看可以看到重名的这个cookie:
虽然JSEESIONID这个cookie重名了,没有关系,因为其值都是一样的,并且如果我们将浏览器关闭后,没有设置cookie有效时间的(也是原先Session发来的)cookie将不复存在(存在浏览器缓存中,浏览器关闭就被销毁),这时重新打开一个浏览器,再去访问SessionDemo2依然能获取到原来Session中保存的内容:
注意,这是另外打开浏览器窗口访问的SessionDemo2!!另附:
通过这里我们可以看到,我们人为地将原先Session定义的cookie给替换了,而Session并不知道,只要能获得“JSESSIONID”这个cookie,它就认为cookie是存在的,可以从这个cookie中id值获取以前保存的信息,因此我们实现了一台主机共享一个Session,此时,当浏览器关闭,或者说结束一个会话后,依然能获取Session来获取之前保存的数据。
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!