Meilleure option pour la gestion de session en Java

La gestion de la session (identification du client, gestion des cookies, enregistrement des données de portée de session, etc.) est essentiellement déjà effectuée par l'appserver lui-même. Vous n'avez pas besoin de s'inquiéter à ce sujet à tous. Vous pouvez simplement mettre/obtenir des objets Java dans la session en HttpSession#setAttribute() et #getAttribute(). La seule chose dont vous avez vraiment besoin est la URL rewriting pour le cas où le client ne prend pas en charge les cookies. Il ajoutera ensuite un identifiant jsessionid à l'URL. Dans le JSP vous peut utiliser les JSTL c:url pour cela. Dans la Servlet vous pouvez utiliser HttpServletResponse#encodeURL() pour cela. De cette façon, le serveur peut identifier le client en lisant la nouvelle URL de demande.

Votre nouvelle question sera probablement "Mais comment les cookies sont-ils liés à cela? Comment le serveur tout faire?". Eh bien, la réponse est la suivante: si le serveur reçoit une demande d'un client et côté serveur (code votre code) est d'essayer d'obtenir le HttpSession par HttpServletRequest#getSession() il n'y a pas créé pourtant (première demande dans une nouvelle session), le serveur en créera une nouvelle lui-même. Le serveur générera un identifiant long, unique et difficile à deviner (celui que vous pouvez obtenirHttpSession#getId()) et définissez cet ID comme valeur du cookie avec le nom jsessionid. Sous le capot, le serveur utilise HttpServletResponse#addCookie() pour cela. Enfin, le serveur stockera toutes les sessions dans une sorte de Map avec l'ID de session comme clé et le HttpSession comme valeur.

Selon la spécification de cookie HTTP le client est nécessaire pour renvoyer les mêmes cookies dans les en-têtes de la demande suivante. Sous le capot, le serveur recherche le jsessionid témoin de HttpServletRequest#getCookies() et déterminer sa valeur. De cette façon, le serveur peut obtenir le HttpSession associé et le rendre à chaque appel sur HttpServletRequest#getSession().

Au point: la seule chose qui est stockée côté client est l'ID de session (dans la saveur d'un cookie) et l'objet HttpSession (y compris tous ses attributs) est stocké côté serveur (dans Java de mémoire). Vous n'avez pas besoin de vous soucier de la gestion de session et vous n'avez pas non plus à vous soucier de la sécurité.

Voir aussi:

• Authentification du nom d'utilisateur, mot de passe à l'aide de filtres en Java (contact avec la base de données)
• Comment rediriger vers la page de connexion lorsque la session a expiré dans l'application Web Java?
• Comment implémenter "Rester connecté" lorsque l'utilisateur se connecte à l'application Web

Tous les frameworks Web Java prennent en charge les cookies ou les identifiants de session codés par URL. Ils choisiront automatiquement la bonne approche, donc vous n'avez rien à faire. Il suffit de demander l'objet session à partir de votre conteneur et il gérera les détails.

[EDIT] Il y a deux options: les cookies et une URL spéciale. Il y a des problèmes avec les deux approches. Par exemple, si vous encodez la session dans une URL, les utilisateurs peuvent essayer de transmettre la session (en mettant l'URL dans un courrier, par exemple). Si vous vous voulez comprendre cela, lisez quelques articles sur la sécurité et la création de serveurs d'applications. Sinon: Votre serveur d'application Java fera la bonne chose pour vous. Ne pensez pas à ce sujet.

Le cookie stocke simplement l'ID de session, cet ID est inutile une fois la session expirée.

La spécification de servlet définit l'API pour accéder/définir les données de session dans l'application J2EE standard. Il définit également que les données de session sont stockées côté serveur et que rien n'est transféré au client à l'exception de l'identifiant de session. Il existe 2 mécanismes de transfert de l'id de session:

1) URL de demande, par exemple jessionid=....
2) cookie

Est déterminé automatiquement en fonction des capacités du client.

MODIFIER . Il n'y a pas de meilleur option, il existe une spécification de servlet qui définit le chemin.

Http est un protocole d'extraction côté client sans état.

Pour implémenter une conversation avec état dessus, le serveur Web Java EE doit masquer certaines informations (qui sont sessionid) côté client et le mécanisme qu'il peut utiliser doit suivre les spécifications HTTP et HTML.

Il y a trois façons d'atteindre cet objectif:

1. URL Rewriting : Le serveur ajoutera un paramètre supplémentaire à la fin du lien URL.
2. Paramètre caché dans le formulaire : le serveur ajoutera un paramètre supplémentaire à chaque formulaire en HTML.
3. cookie : Le serveur demandera au navigateur de maintenir un cookie.

Fondamentalement, le serveur Web moderne aura un "filtre" pour choisir la façon d'utiliser automatiquement.
Donc, si le serveur a détecté que le navigateur désactive déjà le support des cookies, il passera à d'autres moyens.

2 questions importantes:

1. Quelle technologie Web utilisez-vous? JSF, Struts, SpringMVC ou simplement servlets/JSPs.

   • Les servlets / JSP vous offrent déjà le support de session dont vous avez besoin.
     Exemple JSP: Hello, <%= session.getAttribute( "theName" ) %>

   • Je ne pense vraiment pas que vous ayez quelque chose à vous soucier des cookies, car les données sont stockées en toute sécurité sur le serveur et la manipulation du cookie se fait automatiquement.

2. Votre application est-elle installée sur un serveur unique?

   • Si OUI que vous n'avez aucun problème, utilisez l'option session servlet.

   • Si NON, tu dois trouver une autre façon de le faire. Comme utiliser une session collante, ou peut-être analyser l'ensemble de l'objet session dans les requêtes/réponses en tant que champ. Cette option vous oblige en effet à prendre des mesures de sécurité.