Peut-on faire confiance aux sessions

@Thunderseb : tu pourrais stocker les sessions dans un cache de type redis non ? Ou alors c'est ça que tu appelles tableau associatif ?

Après, puisque tu cherches à recoder ce mécanisme, il est primordial que tu te concentres sur l'algorithme de création des sessionId, en t'inspirant fortement (si ce n'est déjà fait) de ce que les ou langages côté serveur.

J'ai rapidement cherché ce qui se fait, et je suis tombé plutôt sur des exemples en PHP, alors que je m'attendais à taper sur d'autres technos, mais ça me semble être enrichissant, notamment dans la partie : oui c'est aléatoire (sinon c'est trop simple à deviner, ofc), mais non ce n'est pas complètement aléatoire (et c'est là que c'est intéressant).

https://github.com/php/php-src/blob/master/ext/session/session.c#L279

http://stackoverflow.com/questions/18937651/php-session-ids-how-are-they-generated

Le cookie c'est l'identifiant de session, pas la session elle même !

Pas, de base, avec RoR. Et rien n'empêche de faire pareil avec PHP si on le voulait, même s'il n'est pas vraiment orienté en ce sens (d'où ma précédente remarque). Tout ça pour dire que ça existait bel et bien (n'était-ce pas la question ?) et que pour le coup on s'éloigne un peu du principe de base.

Au final, tout dépend des besoins : tout conserver côté client, c'est très spécial, mais pour certains ça suffira(it) vs base de données, memcache/redis (qui peuvent assurer eux-mêmes l'expiration de la clé), fichiers, etc. Chaque gestionnaire/implémentation a ses avantages et inconvénients.

Note (j'ai développé en RoR à l'époque de la v2.0 et tous les bouquins ne l'expliquaient pas) :

1. Y'a intérêt à faire extrêmement gaffe à ce qu'on met dans la session. Parce que du texte encodé en base64 c'est pas très compliqué à lire

2. C'est quoi la durée de validité du cookie ? Parce que côté serveur c'est assez simple d'invalider des sessions au bout de X minutes, donc tu limites un peu le risque d'usurpation sur la durée (même si un mec un peu malin va maintenir la session active à vie), mais le cookie j'imagine qu'il est valable ad vitam eternam : attention quand même.

3. Le plus simple, c'est de forcer (je crois qu'en Rails c'est une pauvre option à mettre à true, si c'est comme avec Grails) l'utilisation de SSL sur les pages où une session est active.

Enfin à priori si les données sont relativement sensibles, mieux vaut rester sur une authentification partielle. Personnellement je verais les choses comme ça :

• création d'un token à utilisation unique et à expiration rapide (généré à partir d'un algo complexe et du pseudo du visiteur, par exemple)
• lors de l'utilisation du token, invalidation instantanée et passage en session du demandeur, c'est la partie la plus exposée au hack (cela évite à un pirate de l'utiliser en parallèle s'il intercepte les données)
• blocage des fonctionnalitées sensibles (gestion du compte, mots de passe, …)

Garder le mot de passe même encrypté côté client est trop risqué.

Et bien sûr assurer une connexion encryptée

C'est grosso modo ce que j'ai écrit sur la page précédente

Donc je suis d'accord.

Comme Javier, c'est aussi ce que j'ai mis en page précédente