Comprendre le mécanisme de création des sessions

Le protocole HTTP véhicule les pages HTML du serveur HTTP vers le navigateur de l’internaute. Il s’agit d’un protocole “déconnecté” ou “sans état“, c’est-à-dire qu’il envoie les pages HTTP à l’adresse IP qui les demande, sans se soucier de savoir s’il en a déjà préalablement transmis à cette même adresse. Le serveur HTTP est donc dépourvu de mémoire. Une propriété assez contraignante puisque toutes les applications modernes du web nécessitent de se souvenir des relations établies avec l’internaute.Ce besoin du souvenir se révèle indispensable pour personnaliser les pages d’un portail en fonction de l’utilisateur (il ne peut pas changer d’identité à chaque nouvelle page), pour gérer un panier d’achats sur un site marchand (tous les consommateurs n’ont pas le même panier)… Ce besoin correspond aux fonctions d’un protocole dit “connecté“. Lorsqu’une connexion s’établit entre deux applications, le protocole enregistre chaque transaction. Il est ainsi possible d’annuler la dernière commande, d’obtenir confirmation que celle-ci a bien été exécutée, etc.Dans le cadre d’un échange de page entre un navigateur et un serveur d’application, la mise en ?”uvre d’un mécanisme de session revient au même : lors de chaque échange, il s’agit de vérifier à qui le serveur d’application a à faire. Le serveur HTTP étant dépourvu d’intelligence, le serveur d’application se charge de gérer les sessions.

1 – La création de la session

(1) (Figure 2) Lorsque l’internaute se connecte à un site web ?” que nous appelons site.com ?” pour obtenir la page “index.php“, son navigateur émet un en-tête HTTP du type “GET http://www.site.com/index.php HTTP 1.0“. Cet en-tête est intercepté puis analysée par le serveur HTTP, qui passe la main au serveur d’application compte tenu de l’extension “PHP” du fichier.(2) Le serveur d’application lit le fichier “index.php” à la recherche des instructions à exécuter. Il tombe alors sur la ligne “Session_start();” signifiant que le serveur d’application doit commencer à gérer une session. Il existe plusieurs méthodes pour simuler un protocole connecté. Toutes ont la même stratégie, à savoir écrire un identifiant sur le poste de l’internaute, puis tester cet identifiant par rapport à un référentiel gardé en mémoire du côté du serveur.(3) La première approche consiste à placer cet identifiant de session dans toutes les URL renvoyées à l’internaute. La page “index.php” est donc complètement “parsée” : à chaque fois que le serveur d’application découvre une balise “

” ou ““, il ajoute systématiquement la valeur de l’identifiant de session “sid=12345” en paramètre de querystring. Cette méthode est dite des URL longues.(4) Le serveur d’application renvoie la page à l’internaute. Ainsi, lorsqu’il recevra de nouveau un GET de son navigateur, l’en-tête ressemblera à “GET http://www.site.com/form.php?sid=12345 HTTP 1.0“. Souvent employée, cette solution fonctionne systématiquement, mais oblige l’utilisateur à s’authentifier à chaque connexion.(4 bis) Certains serveurs d’application ne savent pas gérer les URL longues et préfèrent utiliser des cookies. Le principe des cookies se révèle identique, excepté qu’au lieu d’écrire l’identifiant de session dans chaque URL, le serveur d’application génère un en-tête HTTP particulier qui est renvoyé par le serveur HTTP au navigateur du client. Cette en-tête contient une instruction du type “Header(“Set-Cookie: name=sid; value=12345”);“. À sa lecture, le navigateur écrit un petit fichier sur le disque dur de l’internaute puis y stocke l’identifiant de session. Le cookie ne peut donc absolument pas servir à pirater l’ordinateur de l’internaute.En revanche, il autorise la gestion de sessions longues (plusieurs jours, semaines, années), ce qui n’est pas envisageable avec la méthode des URL longues pour des raisons de performance. Il n’est donc pas rare que l’on recourt conjointement à ces deux techniques : les cookies en session longue pour reconnaître l’internaute sans qu’il ait à s’identifier, et les URL longues pour gérer les sessions courtes. Quelle que soit la méthode employée, la création de la session correspond, côté serveur, à la réservation en mémoire d’un index contenant les identifiants de session, ainsi que les valeurs associées.(5) Une fois la session créée ?” prenons par exemple la méthode des URL longues ?” le serveur d’application retourne la page “index.php?sid= 12345” à l’internaute.

2 – L’accès aux informations de session

(6) La récupération d’informations explicites sur l’utilisateur passe obligatoirement par un formulaire. Admettons que l’internaute clique sur le lien “formulaire.php.sid=12345“. Il saisit trois informations : nom, log-in et mot de passe afin de s’inscrire aux services du site réservés aux membres. Lorsqu’il active le bouton “M’inscrire“, le navigateur “pousse” les données vers le serveur d’application (via le serveur HTTP) à l’aide d’un en-tête du type “POST http://www.site.com/formulaire2.php?sid=12345&nom=Dupont&login=Dupont&pass=Tournesol HTTP 1.0“.(7) Le serveur d’application récupère les variables du POST, puis les “monte” en session (dans la mémoire vive du serveur) en suivant deux étapes. La première consiste à déclarer la nouvelle variable de session à l’aide d’une instruction du type “session_register (“snom”);“, tandis que la seconde vise à lui affecter la valeur récupérée du formulaire à l’aide de “$snom=$nom;“. En ASP, la déclaration ne s’avère pas nécessaire ; il suffit d’écrire “session (“snom”)=Request.Querystring(“nom”)” pour obtenir le même résultat. Une fois toutes les valeurs “montées” en session, celles-ci sont accessibles depuis n’importe quelle page ou composant pour toute la durée de la session. L’appel d’une variable de session s’effectue quasiment de la même manière que pour une autre variable : “echo $snom;” en PHP ou “response.write(session (“snom”))” en ASP.(8) Une fois les variables du formulaire en mémoire, il suffit de retourner l’identifiant de session dans chaque page envoyée à l’internaute.

3 – La destruction de la session

La durée de vie d’une session est fixée en fonction d’un paramètre de timeout. Il s’agit de la durée (exprimée le plus souvent en secondes) qui s’écoule après le dernier GET de l’internaute. Le timeout de session peut être court-circuité par la fermeture du navigateur, qui met instantanément fin à la session. Il est également possible de “tuer” une session volontairement, de façon à renforcer la sécurité d’un site, sans que l’internaute ait à fermer son navigateur.En effet, lorsque vous vous connectez au site de votre banque en ligne puis “zappez” sur un site d’information, la session reste active jusqu’à ce que vous quittiez le navigateur. Simple conséquence du timeout ou demandée explicitement par l’internaute, la destruction de la session consiste à vider la mémoire des variables qui ne seront plus utilisées. Il s’agit des instructions “Session. Contents.RemoveAll” en ASP et “session_destroy($phpsessid);” en PHP.

🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.

Frédéric Bordage