Les sessions (sécurité, utilité, optimisation)

[Roworll]

Toi qui utilise le système de session. Peux-tu nous parler des limites d'un tel système ? Tant au niveau maintenance, fiabilité des données ... et expliquer les travers à éviter.

Les sessions sont à la base de simples fichiers contenant une version sérialisée de la variable $_SESSION. L'intérêt d'écrire directement dans la session d'un autre joueur est d'envoyer des informations sans utiliser de bases de données.
Prenons l'exemple de l'envoi d'un message.
Le joueur A envoie un message au joueur B.
Dans la plupart des cas, un champ "message en attente" est renseigné sur l'enregistrement correspondant au joueur. Pour avoir une réactivité optimale et prévenir rapidement le joueur B de l'arrivée d'un message, cette valeur doit être vérifiée à chaque fois changement/actualisation de page.
Cela implique de nombreux accès inutiles en base de données pour vérifier à chaque fois s'il existe un message en attente.

Passer par les variables de session permet de s'affranchir de la base de données. Les variables de session étant chargées à chaque page (du moins lorsque on utilise les sessions), les informations concernant un message en attente le sont aussi et un simple isset() permet de le détecter. On évite donc de nombreux accés en BDD.

Les limites du système est que cela reste ce que l'on pourrait appeler du J2J (Joueur vers joueur). Vouloir mettre à jour les informations de session de tout le monde ne ressemblerait pas a grand chose. Par contre, pour prévenir une personne (ou au pire un groupe de personnes) avec une session active (donc connectée sur le site) c'est impeccable et une excellente alternative au memcache ou APC que Studio Gamboo affectionne tant (certainement à juste titre) mais qui malheureusement est inutilisable sur bon nombre de serveurs mutualisés.

Niveau sécurité, les fichiers de sessions sont gérés par le système d'exploitation / serveur Web. Je suis donc assez peu inquiet de ce coté là.

Roworll, pourquoi éviter les multi-sessions ?
Tu te bases dans un cadre où tu stockes des données sensibles ?

Ce système me permet surtout d'éviter des sessions restant la patte en l'air, des sessions fantômes qui trainent alors qu'elles n'ont plus lieu d'être. Sur mon serveur de test, en windows, elles sont légion à rester dans le dossier de gestion des sessions alors qu'elles sont supposée n'avoir qu'une durée de vie limitée.

Quand aux données sensibles, je ne les mets jamais en session mais toujours en base de données. Si par ce système j'évite le multi session, je peux combattre le multi fenêtrage / l'utilisation d'onglets et les dérives que cela pourrait impliquer en cas de trop grande confiance aux données sensibles placées en variable de session. Rien ne remplace un bon InnoDB avec les transactions pour garantir la cohérence des données.