Faire durer les sessions PHP

[Xenos]

Tu récupères le token d'authentification dans les cookies

Si je comprends bien, cela veut dire que tu crées un cookie-password qui permet de se reconnecter directement (façon "remember me")?! Ca me plait encore moins dans ce cas parce que niveau révocation de ce cookie et sécurité, bof bof.

Selon moi, il faut justement distinguer le cas du GC qui as viré la session (et c'est un bogue de mon ressort, aka du côté serveur) et le cas de l'utilisateur vraiment déconnecté (qui a logout par exemple ou n'est pas revenu depuis plusieurs jours). Sinon, là, t'es finalement jamais de chez jamais déconnecté (c'est le cookie-magique-password qui sert de cookie de session éternel).

[niahoo]

Oui tu comprends bien. C'est toujours plus agréable d'être connecté automatiquement.

Pour se déconnecter il y a un bouton déconnecter. Tu peux aussi faire expirer le cookie, ou donner une date d'expiration à ton auth token (mais dans ce cas il faut le rafraîchir).

[Sephi-Chan]

Les cookies chiffrés s'appellent — dans Rails — signed cookies.

J'ai horreur de me reconnecter donc dans toutes mes applis j'utilise ce système de cookie d'authentification permanente : si je veux déconnecter un user, je change son authentication token. Et généralement je ne conserve presque rien d'autre dans ce cookie chiffré.

Quand je parle de stateless, c'est stateless côté serveur Web : si j'ai un load balancer, les requêtes peuvent bien arriver sur un serveur différent à chaque fois, ça marche.

Depuis quelques temps je fonctionne surtout en API : mon serveur Web ne gère même pas les cookies, du coup je suis complètement stateless au niveau Web : le client envoie avec chaque requête un token (JWT : JSON Web Token) dans son header Authorization. Du coup, même le CORS ne pose pas de problème. Le navigateur peut alors stocker son token en cookie (le serveur l'ignore) ou en localstorage, ou n'importe comment.

[Xenos]

L'auto-connect, j'en suis au contraire pas fan du tout. Dès qu'on a besoin d'utiliser un autre PC (ou à l'inverse, quand quelqu'un utilise notre PC), ça devient incontrôlable. Je préfère effectivement donner une expiration et refresh régulièrement (dans mon cas, la session expire définitivement passée 3 jours, et se renouvelle au delà de 2).

Ok, merci, c'est plus simple de trouver des infos avec la bonne dénomination !

Hmm... Si tu as un authentication token à changer, cela veut dire que tu le conserves quelque part?! Donc on perd le stateless? Ou alors, c'est un token attaché au compte (et non à la connexion de cet utilisateur), et cela déconnecte tous les postes liés à ce compte (sachant qu'Alucard aime bien se servir aussi de son mobile, et que je jongle entre maison et bureau, cela ne me convient pas d'avoir un système comme ça, aussi global)

Intéressant JWT, bien que cela fonctionne finalement sur le même principe... Mais vu le message d'alerte qu'ils mettent en avant, cela me semble encore immature. Je garde tout cela dans un coin quand même

[niahoo]

Sephi as-tu lu cet article qui résume assez bien mon avis sur les JWT : http://cryto.net/~joepie91/blog/2016/06/...-sessions/

Pour le moment je n'ai pas mieux donc on va implémenter ça au taf, mais j'aime pas du tout. Sous prétexte de modernité il te faut au minimum un serveur de blacklist en plus, et de toutes manières tu ne gères pas tous les cas.

[Xenos]

Je plussoie, cela exprime mieux les inquiétudes/semi-objections que j'avais.

Question supplémentaire (pour confirmer si j'ai bien compris): ces objections qui s'appliquent à {JWT stateless with cookies} s'appliquent aussi aux cookies signés, non? Les deux se rejoignent ?

[niahoo]

Non, un cookie signé c'est très bien, c'est même indispensable pour empêcher les cookies trafiqués.

Le principal problème des JWT c'est si tu donne un token qui ouvre une sesssion pour, par exemple, deux jours. Durant ces deux jours, tu n'as pas moyen de révoquer cette sessions sans utiliser un service de blacklist de token, ce qui est chiant, ou bien checker la validité en base de données, et dans ce cas autant utiliser le auth token classique.

Bon mais ça dépend des applis, dans plein de cas c'est très bien avec des tokens valides seulement quelques minutes pour aller récupérer une seule entité.

[Xenos]

Bah, c'est pareil avec un cookie signé servant de session comme Sephi l'a décrit, non? Je ne vois pas la différence entre {JWT [avec les données de session] stateless via cookie} et {cookie signé avec les données [de session] dedans}? L'un (JWT) me semble être simplement une forme d'implémentation de l'autre (d'autres formes existant avec juste d'autres façons de sérialiser les données)?

[niahoo]

Tu as parlé de cookies signés, pas forcément "avec les données de session dedans" donc je t'ai répondu en ce sens".

Bon mais ensuite les cookies pouvant ètre modifiés à chaque requête, tu peux gérer plus simplement l'expiration de session. qu'avec les librairies JWT.

[Xenos]

Okay, compris, merci