JSESSIONID est un terme que vous rencontrez fréquemment lorsque vous travaillez dans le monde Web Java, mais il est difficile de trouver une bonne explication de ce que c’est sur Internet. C’est ce que je vais essayer de faire avec cet article 🙂
Vocabulaire
Présentons un vocabulaire de base pour que vous devez déjà connaître en tant que développeur, mais qui est nécessaire à la bonne compréhension de cet article :
- HTTP : le protocole (principal) qui gère Internet. Lorsque vous demandez un site web, celui-ci est renvoyé via HTTP.
- Client : une application qui demande une ressource (par exemple un site web) à un serveur via HTTP. Votre navigateur web est un client, par exemple – lorsque vous tapez une URL dans la barre de recherche, le navigateur web va aller demander au serveur du propriétaire du site web de le lui renvoyer.
- Serveur : une application qui attend les requêtes HTTP des clients et y répond en mettant à disposition un site internet, ou autres ressources.
- Ressource : dans ce contexte, une information ou site internet mise à disposition d’un client par un serveur.
- Serveur d’applications : une application sur laquelle le serveur s’exécute. Dans le monde Java, le serveur d’applications le plus fréquemment utilisé est Tomcat, mais il en existe plusieurs autres comme Glassfish, Wildfly, Websphere, etc.
Comment marche une session
HTTP est « stateless« . Cela signifie que lorsqu’un client demande un site web à un serveur, chaque requête est indépendante. Cela crée quelques difficultés (enfin pour les créateurs du web, pas pour vous ???? ) : par exemple, disons qu’un serveur dispose d’une page privée (accessible uniquement aux utilisateurs connectés) et d’une page de login. Les utilisateurs peuvent se connecter en utilisant la requête HTTP appropriée, mais comment la requête HTTP suivante fonctionne-t-elle ? Du point de vue du serveur, comment peut-il savoir que la requête qui demande la page privée provient du même client que celui qui a envoyé la requête d’authentification ?
Pour contourner ce problème, une des solutions consiste à utiliser les cookies. Un cookie est un fichier qui contient un texte arbitraire et super long une valeur unique que le serveur envoie au client lorsque le client se connecte. Après cela, le client envoie ce fichier à chaque requête adressée au serveur ; le serveur vérifie que le cookie contient le texte qu’il attend, et si c’est le cas, il sait que l’utilisateur est autorisé à accéder à la page ou à la ressource privée.
Il est important de savoir que cela se produit – de votre point de vue, de développeur -presque automatiquement. Les développeurs développent des sites web qui s’exécutent dans des navigateurs ; les serveurs s’exécutent dans des conteneurs d’applications ; entre les navigateurs et conteneurs d’applications modernes, le processus d’envoi de cookies est automatique et invisible pour les développeurs qui créent les sites web / serveurs. Tout ce que le développeur doit faire est de configurer la sécurité du serveur pour dire « Je souhaite que ces pages soient protégées par des cookies », et les clients et serveurs d’applications feront le reste. Cela permet aux développeurs de sécuriser facilement les applications, mais il est difficile pour les développeurs débutants de comprendre comment tout cela fonctionne et de diagnostiquer quand cela ne fonctionne pas.
Qu’est-ce qu’un JSESSIONID ?
Dans le monde Java, JSESSIONID est le nom du cookie envoyé entre un serveur d’applications et le navigateur. Ce n’est pas seulement une convention, c’est toujours le cas : la Java Servlet Specification indique que « le nom du cookie de suivi de session DOIT être JSESSIONID ».
Réécriture d’URL
Parfois, le client est une application qui ne prend pas en charge l’utilisation de cookies (par exemple, parce qu’elle ne peut pas accéder au système de fichiers de l’appareil et ne peut donc pas enregistrer le cookie ; ou alors, parce qu’il s’agit d’une requête HTTP envoyée avec curl, où le transfert du cookie ne se fait pas comme il se ferait avec un navigateur). Dans ces cas, le JSESSIONID peut être ajouté à l’URL de la requête, en suivant cette syntaxe :
https://christopher-neve.com/private-resource;jsessionid=AB9F3
Notez que ce n’est pas ainsi que VOUS devez envoyer le JSESSIONID à votre application. Cette manière de faire n’est pas la manière préconisée, et ne doit pas être utilisée comme solution de contournement dans le cas où, par exemple, vous ne comprendriez pas pourquoi le JSESSIONID ne s’envoie pas. La sécurité est une préoccupation extrêmement sensible dans la conception et le développement d’une application. La meilleure chose que vous puissiez faire est d’utiliser vos outils, langages et frameworks en suivant les préconisations des concepteurs.
Diagnostiquer des problèmes JSESSIONID
Je reçois des réponses « 401 not authenticated » de mon serveur même si l’authentification a déjà été faite. Comment puis-je m’assurer que le JSESSIONID est transféré ?
Si votre client est un navigateur, cliquez avec le bouton droit sur la page Web et cliquez sur « Inspect », puis sélectionnez l’onglet « Storage » dans vos outils de développement. Sous « Cookies », si votre navigateur a reçu le JSESSIONID, alors il devrait apparaître ici.
Vous pouvez également vous assurer qu’il est envoyé avec les requêtes. Cliquez sur l’onglet « Network », puis cliquez sur la requête qui reçoit la réponse 401. Sous « Request headers », vous devriez trouver un en-tête portant le nom « Cookie » et une valeur commençant par « JSESSIONID= ».
Sources et lectures complémentaires
Java Servlet Specification 2.4, section SRV.7.1.1