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.

eZHumanCAPTCHACode reload
retour

Gestion des sessions

Gestion des sessions

La question de la gestion des sessions mérite une attention particulière. Nous avons dit plus haut que, lorsqu’une application a besoin de retrouver en mémoire des informations de contexte, relatives aux échanges précédents de l’internaute, de la même session, cela amène souvent à mettre en œuvre une répartition de charge avec affinité de serveur.

C’est un mode de fonctionnement qui est souvent retenu, non pas par choix, mais parce que la conception de l’application n’a pas pris en compte le besoin d’extensibilité.

 

Voyons quelles sont les alternatives à une gestion de contexte.

La première chose à dire est que le contexte de session doit être réduit au maximum. Et en particulier il doit comporter de vraies informations de session et non des informations de transaction. Si l’internaute est en train de réserver un billet d’avion dans un processus à plusieurs étapes, les saisies précédentes relèvent du contexte de transaction. Il est préférable que les informations de transaction ne soient pas en session. L’alternative est de les intégrer, soit dans les paramètres d’URL, soit éventuellement dans des champs cachés des formulaires.

Le second point est qu’il existe différentes solutions permettant une gestion de contextes de session sans affinité de serveur. Passons-les en revue.

Partage de sessions par cookies

Principes de fonctionnement

Comme on le sait, le cookie est une donnée conservée sur le navigateur, à la demande du serveur. Le cookie est retourné au serveur avec chacune des requêtes HTTP. Les cookies ont une durée de vie, ou plutôt une date d’expiration, comme les objets en cache. Si la date d’expiration n’est pas indiquée, le cookie est « volatile », il est purgé à la fin de la session, c’est à dire à la fermeture du navigateur. Au contraire les cookies qui restent jusqu’à une certaine date sont des cookies persistants.

Le cookie est retourné soit au serveur qui l’a envoyé (on parle ici de serveur virtuel : en cas de répartition de charge, le cookie est retourné à n’importe lequel des serveurs physiques), soit éventuellement à tous les serveurs du domaine. Mais en aucun cas à un serveur hors du domaine.

Chaque cookie a un identifiant, choisi par le serveur, et tous les couples (identifiant, valeur) de tous les cookies existants pour ce serveur ou son domaine, sont envoyés à chaque requête. Notons enfin qu’il y une limite de taille de 4 Ko pour un cookie. Sur Internet Explorer, la limite est de 4 Ko pour tout un domaine.

Maintenant que l’on a rappelé les grands principes des cookies, voyons comment les utiliser dans le contexte d’architectures hautes performances.

Mauvaise réputation

Les cookies ont mauvaise réputation. D’abord parce qu’ils sont utilisés par différents sites et régies publicitaires pour consolider l’information recueillie sur le comportement et les préférences des internautes. Du coup, certains peuvent même choisir de désactiver ou restreindre la gestion des cookies sur leur navigateur, mais c’est encore une faible proportion des internautes.

La mauvaise réputation des cookies est aussi liée à des questions de sécurité : confidentialité, intégrité, possibilité de vol de cookie. Nous reviendrons sur ces questions plus loin.

Cookie identifiant de session

La plupart des dispositifs de gestion de sessions reposent sur un cookie qui ne porte qu’un identifiant de session. Cet identifiant est la clé permettant de retrouver un contexte de session, conservé côté serveur. Si ce contexte est en mémoire de l’application, il faut que les requêtes d’un même internaute parviennent au même serveur, c’est à dire qu’il faut une répartition de charge « avec affinité de serveur » ou avec « sticky sessions ».

Eviter l’affinité de serveur

 

Sessions et outils de développement

Très souvent, ces questions ne sont pas étudiées en tant que telles : c’est l’environnement de développement qui dicte sa loi. Il gère les contextes de cette manière, et dicte ses contraintes pour l’architecture. Architecture et scalabilité sont vus, trop souvent, comme des problématiques aval : j’ai développé mon application, maintenant quelle architecture vais-je donc choisir ?! C’est la manière de procéder la plus usuelle. Elle convient pour du bas et du milieu de gamme, mais elle ne convient plus pour des plateformes à très haute performance.

Gérer des données applicatives en cookie

Au lieu de stocker un identifiant seulement, les cookies peuvent être utilisés comme gestionnaire de données de session. D’une certaine manière les cookies peuvent aussi un rôle de cache, dans la mesure où l’on y stocke des données issues des bases de données, afin de ne pas avoir à les rechercher lors d’une prochaine requête.

Le cookie en tant que gestionnaire de données a plusieurs avantages :

  • Il est intrinsèquement extensible : que vous ayez 100 utilisateurs ou 1 million, vous ne rencontrerez aucune limite de ce côté-ci.
  • Il ne pose aucune contrainte sur les techniques de répartition de charge, y compris de niveau DNS. Et si l’on utilise un cookie de domaine, alors tous les serveurs du domaine partagent l’information du cookie.
  • L’information placée dans le cookie peut être utilisée aussi bien côté serveur que côté client, puisqu’un petit programme Javascript peut accéder à ces informations.
  • Enfin, il peut être persistant, au delà d’une session, c’est à dire que c’est une sorte de cache que l’on peut retrouver une semaine plus tard, pour autant bien sûr que l’utilisateur utilise le même poste.

A l’inverse il a quelques inconvénients :

  • Il induit un petit poids sur le trafic réseau, quelques kilo-octets par requête. C’est peu de chose comparé aux poids de pages usuels, mais il faut se souvenir que la bande passante dans le sens client vers serveur est sensiblement moindre en ADSL.
  • Il faut analyser la question de la cohérence : lorsqu’une application reçoit des données stockées en cookie sur un poste, elle ne sait pas s’il s’agit de la dernière version de ces données.
  • Différents problèmes de sécurité sont à traiter enfin, pour garantir l’intégrité, voire la confidentialité du cookie, ainsi que l’impossibilité de voler un cookie.
  • Il existe des risques d’incohérence, par exemple si l’utilisateur fait un ‘back’ (précédent) sur son navigateur, le cookie reste inchangé.

Revenons sur ces difficultés. La question de la cohérence se règle partiellement en se limitant à des durées de vie réduites. C’est à dire que l’utilisation du cookie persistant pour stocker de l’information est rarement possible car on ne sait pas dans quelle mesure cette information est valide une semaine plus tard, et donc le serveur ne peut rien en faire avant d’avoir récupéré l’information de référence, sans doutes auprès d’une base de données.

Les différents problèmes de sécurité peuvent être résolus par un peu de cryptographie. Typiquement, on ajoutera aux données un horodatage, et on cryptera le tout avec un simple algorithme symétrique, ou bien un algorithme de scellement tel que SHA-5 portant sur le contenu du cookie PLUS une clé secrète uniquement connue côté serveur.

Partage de contexte côté serveur

Nous avons vu que l’une des voies pour éviter de conserver un contexte de session au niveau des frontaux web est d’en transférer la gestion côté client, aux navigateurs, via les cookies. L’autre possibilité est de la transférer côté serveurs, à l’étage de la gestion des données, qui est l’étage naturellement dédié au partage de données.

Si le contexte de session est conservé en base de données, il peut être accédé et mis à jour à partir de n’importe quel serveur frontal. C’est donc une voie qui permet à la fois une répartition de charge sans affinité, et néanmoins un partage de contexte. Et différents outils de développements permettent de rendre cela transparent pour le développeur.

L’inconvénient est un petit impact en performances : un accès à la base de données, même très simple, est beaucoup plus coûteux qu’une lecture en mémoire.

Partage de contexte en cache global

Une autre alternative consiste à partager les contextes de sessions au moyen d’un outil de cache global, tel que memcached. Comme on le verra ce type d’outil, bien que distribué sur un ensemble de serveurs, maintient une copie unique de chaque objet qui lui est confié. N’importe quel serveur frontal peut donc récupérer le contexte de session et le mettre à jour. L’accès est distant, mais purement en mémoire, avec donc des performances à mi-chemin entre celles d’une gestion locale, et celles d’une gestion en base.

Synthèse

La figure suivante fait apparaître les différentes solutions de gestion de session évoquées :

image052