Comment empêcher correctement plusieurs sessions actives dans ASP.NET Identity 2.2.1 sans affecter le comportement de changement de mot de passe?

Question

J'ai une obligation d'éliminer plusieurs sessions actives d'être autorisés sur notre site.

Je crois comprendre que, pour ce faire, vous pouvez manipuler le paramètre validateInterval de la propriété OnValidateIdentity du CookieAuthenticationProvider comme ci-dessous:

Provider = new CookieAuthenticationProvider 
    { 
     // Enables the application to validate the security stamp when the user logs in. 
     // This is a security feature which is used when you change a password or add an external login to your account. 
     OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser>(
      validateInterval: TimeSpan.FromMinutes(0), //Changed from default of 30 minutes 
      regenerateIdentity: (manager, user) => user.GenerateUserIdentityAsync(manager)) 
    } 

J'ai changé la valeur par défaut de 30 minutes à 0 pour les essais et il fonctionne comme anticipé. Si je me connecte à un deuxième navigateur, l'action suivante dans le premier navigateur me redirige vers la page de connexion.

Je permets également aux utilisateurs de changer leur mot de passe quand ils veulent (après la connexion). Avec la propriété validateInterval à zéro, l'utilisateur est déconnecté immédiatement après avoir soumis un changement de mot de passe. Ils se connectent ensuite avec le nouveau mot de passe et peuvent utiliser le site normalement. Si je change la valeur du paramètre validateInterval en 10 secondes, l'utilisateur est autorisé à continuer la session en cours après avoir soumis un changement de mot de passe pendant 10 secondes, puis est redirigé vers la page de connexion.

Dans l'action ChangePassword de la classe ManageController le code par défaut qui court après un changement de mot de passe avec succès est la suivante:

if (result.Succeeded) 
{ 

    var user = await UserManager.FindByIdAsync(User.Identity.GetUserId()); 
    if (user != null) 
    { 
     await SignInManager.SignInAsync(user, isPersistent: false, rememberBrowser: false);      
    } 
    return RedirectToAction("Index", new { Message = ManageMessageId.ChangePasswordSuccess }); 
} 

Je pensais que la ligne SignInManager.SignInAsync garderait la session de l'utilisateur allant même par un mot de passe change (à partir de Logout User From all Browser When Password is changed), mais il semble être contrôlé en plus par le paramètre validateInterval.

Si je voulais permettre à un utilisateur de changer son mot de passe pendant une session authentifiée sans forcer puis de se connecter à nouveau, est-ce que je pourrais le faire avec ASP.NET Identity et contrôler plusieurs sessions actives? Existe-t-il un meilleur moyen de contrôler plusieurs sessions actives sans modifier le paramètre validateInterval (à partir de Prevent multiple logins)?

Nous vous remercions de votre aide. Pour clarifier, si ce comportement est voulu, je vais bien. Je veux juste comprendre ce qui se passe afin que je puisse défendre le comportement à mon patron si nécessaire.

Edit:

J'omis de mentionner que je mets à jour aussi le timbre de sécurité directement avant le signe via SignInManager dans l'action de connexion.

Answer 1

Ce que vous faites n'empêche pas plusieurs sessions actives. Je suppose également par «sessions» que vous parlez de plusieurs authentifications par le même compte d'utilisateur. Plusieurs sessions actives, dans le vrai sens du terme, est une discussion entièrement différente. Cela dit, le cookie configuré pour conserver l'état "authentifié" de l'utilisateur est spécifique au client. Si je me connecte à partir de mon ordinateur de bureau et de mon appareil mobile, ou même à partir de Chrome et d'Internet Explorer sur le même ordinateur, tous les cookies sont différents, non affectés par d'autres cookies installés sur d'autres appareils ou navigateurs. La seule façon de vraiment empêcher cela est de marquer l'utilisateur comme étant "connecté" côté serveur (c'est-à-dire une colonne sur votre table utilisateur par exemple). Ensuite, avant de les authentifier ailleurs (essentiellement dans l'action de publication de votre signature), vous devez vérifier leur compte utilisateur pour ce drapeau. Si c'est déjà fait, vous refusez de les reconnecter jusqu'à ce qu'ils se déconnectent pour la première fois sur le périphérique/navigateur d'origine.Évidemment, votre action de déconnexion devra alors désactiver ce drapeau, afin qu'ils soient autorisés à se reconnecter ailleurs.