Architectures web hautes performances en bases de donn�es �paisses

1. Le probl�me des cookies dans la gestion des sessions applicatives PHP

Pour aller droit au but, placer les cookies au centre de votre strat�gie de gestion des sessions PHP pour vos applications web est une tr�s mauvaise id�e et reste � proscrire. En voici les principales raisons.
- Un cookie est stock� au niveau client applicatif et donc � l'ext�rieur de l'environnement de gestion d'une application web qui se situe c�t� serveur.
- �tant dans un environnement n tiers, chaque tiers ne peut faire confiance � ce qu'il re�oit de l'autre. C'est la r�gle fondamentale � appliquer au niveau s�curitaire.
En cons�quence, ce qui est plac� du c�t� navigateur client rel�ve du domaine "public" pour votre application, ce qui ne peut �tre d�cemment consid�r� comme source de confiance pour authentifier un utilisateur au sein de votre applicatif.

Rappel : Un serveur PHP utilise d�j� un cookie en gestion interne pour authentifier un utilisateur sur le serveur web. C'est une obligation technique, il reste incontournable et reste transparent pour tout le monde. Il ne sert � rien � rajouter un cookie applicatif qui reste une aberration � la vue de ce qui pr�c�de.

Utilisez des cookies sur vos sites, � des fins marketing et de prospection, en respectant la r�glementation, est une fa�on justifi�e d'utiliser des cookies, et je vous recommande vivement de vous en tenir � cette utilisation professionnellement parlant.

2. Les besoins techniques

a. Une session PHP ne doit pas �tre trop longue

Plusieurs raisons � cela. Comme il est expliqu� dans la documentation PHP, le module de sessions PHP n'est pas prot�g� naturellement contre les attaques au niveau des sessions, notamment via javascript. Plus une session est longue, plus elle a de chances d'�tre intercept�e et utilis�e pour acc�der � des informations normalement prot�g�es.

Principe n�1
La premi�re chose donc pour limiter la surface d'attaque de nos applications en PHP, consistera � faire en sorte d'avoir des sessions relativement restreintes dans la dur�e.

Seulement dans une application web d'entreprise, les utilisateurs d�testent devoir se reconnecter 50 fois dans la m�me journ�e, surtout si le mot de passe est compliqu�. Id�alement, il faut �viter de le faire plus de 2 fois par jour. Le plus g�n�ralement constat�, apr�s discussion avec des responsables en entreprise sur les enjeux au niveau s�curit�, il est g�n�ralement souhait� une p�riode de session sans interruption comprise entre 3 et 4h.

Une des premi�res solutions se pr�sentant � nous pour r�soudre ce probl�me et atteindre ce minima de 3 � 4 heures est de jouer sur la configuration de PHP au niveau du serveur afin de repousser le timeout de connexion PHP et la p�riode du Garbage collector � cette limite. Le seul avantage est la simplicit� de gestion ici, mais voil� : les d�savantages sont tr�s nombreux. Parmi les principaux, citons :

• La r�duction de la capacit� de monter en charge du serveur HTTP, et la r�duction drastique du nombre de connexions concurrentes pouvant �tre g�r�es par le serveur. En effet l�optimisation d�un serveur web passe avant tout par la r�duction optimale du temps de r�ponse d�un serveur � une requ�te HTTP/HTTPS afin d�en lib�rer les ressources au plus t�t et permettre � une autre requ�te de se pr�senter.
  
• On ne respecte pas le principe n�1 pour r�duire la surface d�attaque de notre application.

Principe n�2
Les vieilles sessions doivent �tre maintenues jusqu'� leur prise en charge par le gc (garbage collector)
Ne pas faire ainsi s'est s'exposer � des comportements instables voire erratiques dans un contexte concurrentiel.

Principe n�3
session_regenerate_id(true) et session_destroy() ne doivent jamais �tre utilis�es ensemble pour une session active.
Ce principe est directement issu du principe pr�c�dent.

b. G�rer les sessions via un double axe au minimum : PHP + Base de donn�es et id�alement sur un axe triple : PHP + DB + Cache Redis
Une fois �limin� la solution pr�c�dente qui fait le travail certes, mais qui n'est pas satisfaisante techniquement (dans un contexte d'optimisation d'infrastructure) et surtout au niveau s�curit�, il s'impose de suite la gestion selon un axe double.

Axe double : PHP + DB
Si on souhaite garder des sessions PHP � dur�e standard dans une configuration standard par d�faut pour le moins d�un c�t� et satisfaire � notre client�le, en leur permettant de ne pas se reconnecter avant 3 � 4 heures de travail, tout en ne travaillant pas sur leur poste de travail en mode continu, mais permettre un travail effectu� par intermittence et donc avec des p�riodes d�inactivit� incluses dans ce laps de temps imparti, on n�a pas le choix :

=> On g�re la dur�e de connexion applicative en base de donn�es et on g�re les sessions techniques pour traiter les requ�tes clients sur le serveur applicatif du c�t� PHP.

On peut donc d�duire d'un tel sc�nario les �v�nements suivants :

• Une session applicative aura plusieurs id de session PHP diff�rentes au cours de sa vie.
  
• Le gc va intervenir plusieurs fois au cours de la vie de notre session applicative.
  
• A chaque intervention du gc on va devoir maintenir le contenu de la session PHP
  
• le gc va intervenir sur des sessions pass�es et obsol�tes ( pas de probl�me de transmission de session), et peut intervenir aussi sur la session en cours en cas de p�riode d'inactivit� trop longue de l'utilisateur (probl�me de transmission de session).

Gestion du probl�me de transmission du contenu de session
En cas de p�riode d'inactivit� trop longue de l'utilisateur, il y a un risque de perte de contenu de session, et ce, d'autant plus que la p�riode du gc fix� est faible. Il faut donc stocker le contenu s�rialis� des informations de session ailleurs que dans le syst�me de gestion de sessions de PHP et ailleurs que dans un cookie bien �videmment. Une des meilleures pratique qui est recommand�e dans la documentation de PHP est de l'�crire dans un fichier sur disque hors dossier de sessions donc.

=> L'endroit ou l'on va sauvegarder ces informations de session constitue donc le 3e axe de gestion.

Si l'on reste ici sur un paradigme PHP+DB, on devra stocker l'information en DB.

Rappel de ce qui est stock� au niveau session

• Il n'y a pas de variable globale stock�e directement en session pour pr�server les principes de la POO.
  
• On recommande donc d'y stocker des objets s�rialis�s. En g�n�ral, comme on l'a vu dans un pr�c�dent billet, il y a en a au moins 3 : une classe utilisateur, une classe connexion et une classe module applicatif.

Les donn�es de type utilisateur et connexion sont limit�es et peuvent �tre restitu�es par la base de donn�es. Il s'agit tout au plus d'une dizaine de variables selon l'applicatif concern�.
Les donn�es de type module applicatif, quant � elles, sont sp�cifiques � la navigation de l'utilisateur et de ce qu'il a fait au cours de sa session de travail. Il y aura donc dans ce type de donn�es des donn�es calcul�es sp�cifiques mises en cache. Elles sont de nature non pr�dictive et il peut �tre tr�s co�teux de les recharger � partir de la base de donn�es. Pour le moins, l'exp�rience utilisateur s'en ferait sentir dans un contexte de charge au niveau des performances applicatives, si l'on d�cidait de ne pas maintenir ces donn�es dans ce contexte de transmission de session.

On pourrait bien �videmment scinder la gestion des deux premiers types de donn�es avec le troisi�me. Dans un tel sc�nario qui obligerait � stocker en variable globale cette fois un tableau s�rialis� des modules consult�s par l'utilisateur et � g�rer sp�cifiquement leur contenu � part hors db pour �viter de la solliciter et garder une capacit� de mont�e en charge applicative optimis�e, il y aurait un surco�t de gestion applicatif au prix de quelques efforts, mais cela resterait � prototyper au niveau performances pour se faire une bonne id�e de la chose. Toujours dans un tel sc�nario, le rechargement des deux premiers types de donn�es � partir de la base, bien que tr�s limit� et localis�, provoquerait une augmentation de charge pr�judiciable � l'applicatif.

Pr�f�rer/Privil�gier une gestion � trois axes
Du plus performant au moins performant, voici les choix � privil�gier dans un tel contexte de gestion de session.

• Sauvegarde de l'int�gralit� du cache de session (3 types de donn�es) dans REDIS

Le cache �tant tr�s rapide et g�r� en m�moire, il n'y aura pas plus performant. Attention cependant, g�rer les sessions PHP directement dans REDIS n'a rien � voir avec ce qui est expos� ici, puisque le cache de session PHP dans REDIS serait soumis aux m�mes r�gles du gc que s'il �tait g�r� de fa�on traditionnelle. Cette solution � l'avantage en plus, d'�tre transparent techniquement dans le cloud.

• Sauvegarde de l'int�gralit� du cache de session (3 types de donn�es) sur disque

Solution � privil�gier par d�faut donc surtout lorsqu'on est pas encore � l'aise avec la gestion d'un cache sp�cifique comme REDIS.

Note
Que cela soit avec REDIS ou directement sur Disque, rien n'emp�che d'utiliser un plugin PHP de binarisation de donn�es s�rialis�es (plugin compil� sur serveur) qui apporte un gain de performances notable dans un contexte de forte charge applicative et qui a fait ses preuves, m�me si cela ajoute un traitement suppl�mentaire des donn�es concern�es. Un tel syst�me est impl�mentable sur Microsoft Azure.

2. Algorithme d'impl�mentation
Je recommande de diviser votre algorithme en deux parties distinctes. La premi�re concerne la connexion initiale de l'utilisateur, lorsqu'il se connecte � l'application. La seconde concerne le ping de connexion au moment o� une requ�te utilisateur est envoy�e au serveur (rafraichissement du navigateur, requ�te ajax, ...). On pr�f�rera travailler ainsi en mode passif (pull) sur action de l'utilisateur pour optimiser la capacit� de mont�e en charge du serveur (on lib�re les ressources au plus t�t) plut�t qu'en push, qui consomme des ressources en permanence et limite potentiellement le nombre d'acc�s concurrentiels � l'applicatif beaucoup plus vite.

Il est probable voire fortement probable (je ne l'esp�re pas) que vous soyez oblig� de mettre en place des variables de gestion qui n'existaient pas jusqu'� maintenant dans votre environnement de gestion de sessions applicatif.
Voici celles que j'impl�mente dans mes solutions et qui me paraissent incontournables et minimales.

• datetime de connexion
• datetime derni�re requ�te serveur
• session_id() PHP
• Informations navigateur utilisateur ayant initi� la connexion
• Adresse IP utilisateur connect� ayant initi� la connexion
• Id technique de l'utilisateur connect�
• Les donn�es s�rialis�es � maintenir
• La dur�e maximale de session applicative
• La dur�e de vie configur�e de votre gc

Remarques / Conseils
Essayez de ne conserver et de g�rer au niveau des variables de gestion que le strict n�cessaire pour offrir un service de qualit� et s�curis�, tout en ayant la possibilit� d'auditer sereinement vos sessions en cas d'anomalie constat�e. Trop de volum�trie au niveau de la base a aussi ses cons�quences et ne reste pas anodine.

� vous d'impl�menter vos algorithmes