(02-12-2008, 11:34 PM)rygnes a écrit :Je ne voyais pas non plus l'utilité d'un tel système avant de découvrir que si je me connectais sous deux navigateurs sur le même compte, je créais deux sessions (ça peut sembler logique, mais ça ne m'avait jamais frappé). Or si je me base en partie sur les sessions, il est difficile de coordonner les actions des deux sessions.Holy a écrit :Personnellement, dans tous mes jeux, j'empêche absolument une double connexion sur un même compte (petit script)
Une double connexion oui. Mais pas le vol de session.
Je ne comprends pas bien l'utilité de ce système, peux tu l'illustrer par un exemple pratique s'il te plaît ?
Exemple: Un joueur se trouve sur une map, il a droit à X déplacements par jour. Le nombre de déplacements restant est stocké dans une variable de session. Je n'ai qu'à me déplacer d'abord avec firefox par exemple, épuisé les déplacements sur cette session. Et ensuite me déplacer avec IE. Etant donné que ce sont deux sessions distinctes pour le même compte, je multiplie mes capacités par deux (ou plus si on utilise encore d'autres browsers).
Ce système n'est valable uniquement que si le script se base sur les données de session. Si vous vérifiez régulièrement avec la base de données, forcément, ça ne servirait pas à grand chose.
J'utilise un fichier dans lequel j'ai un tableau avec les identifiants de session courants de tous les joueurs. Dés lors que quelqu'un se connecte sur le même compte, je crée un fichier temporaire ayant pour nom l'ancien identifiant de session (sid) courant.
A chaque début de page, je vérifie l'existence d'un fichier portant le nom du sid, si il existe, déconnexion forcée et suppression du fichier.
Le dossier contenant les fichiers provoquant la déconnexion est nettoyée régulièrement pour éviter qu'il y en aie 20 000 ^^
J'ai expliqué en gros le principe. Dans le détail, c'est plus propre que ça, puisque lorsqu'une personne se déconnecte de son plein gré, son "sid" est supprimé du tableau reprenant tous les sid courants, etc.
Edition: De fait, ça n'empêche pas le vol de session. A mon sens, le vol dépend plus du codeur que de l'utilisateur. En sécurisant bien les champs, c'est rare que ça arrive.