Faire durer les sessions PHP

[Xenos]

Je relance le sujet: finalement, j'ai craqué... La complexité amenée par le mutualisé et le fait de devoir stocker un "backup" des sessions en DB pour éviter le garbage collect sauvage s'est téléscopée avec le besoin d'une cron task pour faire le garbage collect sur la DB (et ne pas garder les sessions d'il y a 2 semaines) plus le fait de requérir des connexions à la DB dans la page à des moments qui ne me plaisent pas (hors de la transaction principale de la page)... Et j'ai évidemment planté des trucs au milieu (la session n'était pas restaurée de la DB par exemple: si la session du client n'existe plus chez OVH, je regardais dans la DB si j'avais un backup de session, et si oui, j'en prenais les données... sans recréer la session PHP).

Bref, du coup, j'ai voulu dégager ce concept lourd et je l'ai remplacé par un cookie signé: json_encode([id joueur, date expiration, signature])
La date d'expiration est réglée à T+48H, et le cookie est renouvelé à 24H de l'expiration (donc à T+24H)
De cette façon, pas de soucis de garbage collect côté OVH (je n'ai même plus de session: elles me serviront éventuellement de "cache" peut-être.. c'est pas adapté, mais on verra bien, pour le moment, elles servent pas de toute façon!), et plus de cron task.

Pour la signature, je suis parti sur hmac(SHA256, concaténer(id paddé de 0 à gauche à 10 digits, date expiration paddée de 0 à 10 digits), token commun à tout le serveur)
Ca me permet pas de couper une session précise. Cela m'empêche même de déconnecter un éventuel "pirate" à cause du renouvellement automatique du cookie de session. Cela me permet de couper toutes les sessions si besoin (en changeant le token). Cela m'évite tout accès à la DB pour l'authentication. Cela me permet de couper toutes les sessions d'un compte (difficilement) si besoin (je change alors l'id du compte en DB: les cookies référenceront un compte inexistant et donc, les sessions actives de ce compte ne marcheront plus).

Je pense que ce sera suffisant, et simple, pour un jeu web

[niahoo]

Ou sinon tu fais juste un call ajax toutes les minutes qui rafraîchit la session. Il n'y a normalement pas besoin de la modifier pour qu'elle n'expire pas. Et tu peux donc garder la gestion basique de la session de PHP.

[Xenos]

Non, parce que le call n'aura pas lieu quand tu iras te coucher, et le lendemain, tu devras te reconnecter (et j'en ai vu qui n'aiment pas se reconnecter : ) et je suis d'accord)

[niahoo]

Hmm tu mélangerais pas les notions de session et de connexion automatique ?

[Xenos]

Je ne suis pas partisan du tout d'avoir en plus un cookie de connexion automatique... :/ Je préfère donc ne pas avoir de connexion automatique, et renouveler la durée du cookie de session quand celui-ci approche de la fin (après, à voir s'il faut mettre 48H, 24H ou 1 semaine, cela dépendra du rythme de jeu mais je pense qu'en dessus de 72H, cela dénotterait un jeu pas assez addictif).

Je ne serai d'ailleurs même pas sûr qu'un GC des sessions ne passerait pas malgré tout (malgré les boucles de ping back, qu'au passage je déteste aussi) par là... Vu que c'est un mutu, toutes les sessions des sites (des miens au moins j'entends) sont dans le même panier. Le GC de l'un ira donc nettoyer les sessions de l'autre, et impossible de gérer proprement les durées de vie dans ce cas

[Sephi-Chan]

Je trouve un peu dommage de perdre la possibilité de déconnecter un joueur en particulier, surtout pour seulement s'épargner une requête SQL par page.

J'aime vraiment le principe du token de persistance propre à chaque utilisateur. C'est simple et ça fonctionne très bien. Tu as ensuite un contrôle total sur ce que tu en fais : si tu veux faire passer un cron qui change le token pour déconnecter les gens au bout d'un certain temps. Je préfère laisser les gens tranquilles et ne jamais leur demander de se reconnecter.

[Xenos]

Je préfère au contraire ne pas rajouter de la lourdeur: j'aime le fait de ne pas avoir de cron pour nettoyer des sessions serveur obsolète. J'aime le fait de ne pas avoir besoin de me tordre la tête façon "ok, la session n'existe plus, donc je regarde le cookie d'auto-connexion, qui doit matcher un truc en DB, est-ce que je le fais rotater alors? est-ce que je clear le cookie de session? est-ce que la session n'a pas déjà été fermée quand je fais ça? Quid d'accès concurrents? blabla".

Oui, c'est clair que pour une appli bancaire, je ne l'aurai pas fait (eût égard au fait que je n'ai qu'un token global au serveur, et non 1 token / joueur; rien ne m'en empêcherai par la suite (je me repalucherai alors la problématique de transactionner correctement ce nouvel appel), mais je n'en ai pas besoin actuellement donc, je n'en mets pas). Pour un jeu web, c'est surfait. D'autant qu'une solution (si besoin) simple (un poil bourrin) consiste juste à changer l'id du compte en BDD, les anciennes sessions faisant alors référence à un ID inexistant. On reste connecté, mais plus au même compte. Bref, on verra à ce moment-là

[Sephi-Chan]

C'est dans la tête la lourdeur ! :p
Dans mes applications, j'ai plus ou moins toujours une méthode :

def current_user

  cookies[:persistence_token] && User.find_by_persistence_token(cookies.signed[:persistence_token])

end

Ça me retourne l'utilisateur ou rien, c'est tout.
Le code est trivial et quand j'ai besoin d'implémenter un mécanisme d'expiration (ça a déjà été le cas pour des clients), je le fais dans cette méthode.