En regardant les cookies de Gmail, il est facile de voir ce qui est stocké dans le cookie "se souvenir de moi". Le nom d'utilisateur/jeton d'accès unique. Il pourrait être mis en œuvre différemment dans les cas où le nom d'utilisateur est également secret. Mais peu importe ... la sécurité n'est pas très élevée: vous volez le cookie et vous êtes prêt à partir.
Ma question concerne toutefois le côté fonctionnel: quand effacez-vous leurs jetons d'accès? Si un utilisateur se connecte sans en cliquant sur "Remember me" sur une autre machine, doit-il invalider ses jetons d'accès sur toutes les machines ? Je demande comment cela est traditionnellement mis en œuvre et comment il devrait être mis en œuvre.
J'utilise régulièrement 2 ou 3 machines simultanément et j'ai «se souvenir de moi» sur chacune d'elles. Si l'un d'eux déconnectait les autres, ce serait très agaçant, alors je ne le recommanderais pas.
Traditionnellement, le cookie expirait après un certain délai (ou lorsque l'utilisateur se déconnectait).
Tout dépend de votre modèle de sécurité. Si vous écrivez une application d'entreprise interne dans laquelle vous ne vous attendez jamais à ce qu'un utilisateur se trouve sur un seul ordinateur, vous souhaiterez peut-être appliquer des restrictions plus strictes que gmail.
Pensez également à la possibilité d'un déni de service. Si une action sur une machine peut forcer une autre machine à être inutilisable, vous pouvez l'utiliser pour empêcher un utilisateur légitime de reprendre le contrôle dans certains scénarios.
Les articles Meilleure pratique de connexion persistante et Meilleure pratique de connexion persistante améliorée sont d'excellentes références sur la manière de mettre en œuvre ce type de fonctionnalité.
Voir aussi ces questions sur StackOverflow
La connexion depuis un autre ordinateur ne doit pas invalider la connexion associée à un cookie sur un autre ordinateur. Cependant, si les utilisateurs se déconnectent ou "pas vous? Connectez-vous ici", cela devrait effacer le cookie sur lequel l'utilisateur travaille.
Soit dit en passant, voler un cookie peut être compliqué, en insistant sur https et en le rendant ainsi inutile pour les scripts.
En ajoutant "; HttpOnly" à la sortie de votre cookie, cela rendra le cookie indisponible pour javascript, par exemple.
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
Set-Cookie: ASP.NET_SessionId=ig2fac55; path=/; HttpOnly
X-AspNet-Version: 2.0.50727
Set-Cookie: user=t=bfabf0b1c1133a822; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Tue, 26 Aug 2008 10:51:08 GMT
Content-Length: 2838
vous pouvez en savoir plus à ce sujet
Le cookie Remember me devrait également identifier la machine. Cela doit être lié à la machine car il y a des endroits où vous voulez vous rappeler et d'autres endroits où vous ne le souhaitez pas (domicile vs travail).
La date d'expiration est généralement définie sur une période raisonnable (deux semaines) ou après que l'utilisateur s'est explicitement déconnecté de la machine,
Ce que je voudrais faire est de lier chaque session à une adresse IP. Si le jeton de session est envoyé depuis une adresse IP différente de celle que vous avez, rejetez-le.
Les jetons d'accès doivent être spécifiques à IP afin qu'ils ne puissent pas être facilement transférés sur des machines.
Ils doivent également être implémentés de manière à permettre aux utilisateurs de voir sur quelles machines ils ont des jetons actifs.
Les sites qui choisissent d'éliminer un jeton une fois qu'un nouveau jeton est créé sur un autre ordinateur - indiquent que leurs utilisateurs n'auront pas accès à leur service sur plusieurs ordinateurs - ou s'ils le font - que leur utilisation justifie de les reconnecter.
La stratégie que vous employez dépend vraiment des données que vous possédez et des besoins de l'utilisateur.