Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

retour

Sessions et contextes

Sessions et contextes

Par essence, le protocole Http est un protocole sans connexion, c’est à dire que rien ne relie entre elles les différentes requêtes venant d’un même utilisateur.

L’enchaînement des différents échanges avec un même utilisateur constitue une session.

La plupart des applications web ont besoin de mémoriser certaines informations au travers d’une même session, c’est à dire que le traitement d’une requête pourra dépendre d’informations mémorisées lors du traitement de requêtes antérieures de la même session. Le cas le plus courant est l’identification de l’utilisateur. Si l’accès à une application implique identification, alors le traitement des requêtes au sein de l’application n’est pas le même selon que l’utilisateur a été identifié au travers d’une requête antérieure ou non.

L’ensemble des informations mémorisées au travers d’une même session constitue le contexte de session. Ainsi le contexte de session peut contenir une variable indiquant s’il y a eu identification ou non au sein de la session, et le cas échéant, l’identifiant de l’utilisateur et son profil.

On dit qu’un tel contexte de session est géré « coté serveur », c’est à dire du coté de l’application, sans apparaître du coté du poste de travail, le « coté client ». Un tel contexte est un contexte implicite, c’est à dire que l’URL ne porte pas l’information de contexte.

Quand nous disons des informations caractérisant la session dans son ensemble, il s’agit typiquement de l’identifiant utilisateur, de son profil, de ses préférences, par exemple la langue d’interface pour une application multi-lingue, etc…

A l’inverse, des informations propres à un contexte de travail seraient par exemple des critères de filtrage sur telles entités, le contenu d’un formulaire

issu d’une première étape de saisie, le numéro de la dernière page vue dans une liste, etc. Ces informations doivent être gérées dans l’URL.

Supposons par exemple que sur une page l’utilisateur définit des critères de recherche. L’application peut mémoriser ces critères coté serveur dans son contexte de session. Lorsque l’utilisateur revient à la page de liste, l’application retrouve les critères et filtre la liste en conséquence.

Cette technique présente plusieurs inconvénients :

  • On casse le principe fondateur d’une association un-pour-un entre une URL[1] et une page web. Si l’utilisateur définit un bookmark, ou bien sélectionne l’URL pour l’envoyer par e-mail à un collègue, cette URL ne produira pas la page attendue.
  • L’association URL-page est également l’hypothèse de base des moteurs d’indexation, qui ne pourront donc pas œuvrer sur ces pages.
  • Si l’utilisateur a ouvert deux fenêtres et définit dans l’une et l’autre des critères de recherche différents, l’application mélangera les deux contextes, et le résultat sera un filtrage imprévisible.
  • De même l’utilisation du bouton ‘précédent’ ou plus largement de la fonction historique du navigateur sera totalement perturbée.

Ainsi imaginons que l’utilisateur a dans l’historique de son navigateur parcouru une page de liste filtrée selon des critères C1, puis plus tard la même page filtrée selon des critères C2. Lorsqu’il revient, par le bouton ‘précédent’ sur la première page, elle est restituée en cache correctement. Mais s’il demande à rafraîchir la page, il la verra soudainement filtrée selon les critères C2 ! !