如何在不影响密码更改行为的情况下正确防止 ASP.NET Identity 2.2.1 中的多个活动会话?

How do I properly prevent mulitple active sessions in ASP.NET Identity 2.2.1 without affecting password change behavior?

我需要消除我们网站上允许的多个活动会话。

据我了解,要执行此操作,您可以如下操作 CookieAuthenticationProvider 的 OnValidateIdentity 属性 的 validateInterval 参数:

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))
    }

我将默认值从 30 分钟更改为 0 以进行测试,它按预期工作。如果我登录到第二个浏览器,在第一个浏览器中执行的下一步操作会将我重定向到登录页面。

我还允许用户随时更改密码(登录后)。当 validateInterval 属性 为零时,用户会在提交密码更改后立即注销。然后他们使用新密码重新登录并能够正常使用该站点。

如果我将 validateInterval 参数值更改为 10 秒,则允许用户在提交密码更改 10 秒后继续当前会话,然后被重定向到登录页面。

在 ManageController 的 ChangePassword 操作中 class 在成功更改密码后运行的默认代码是这样的:

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 });
 }

我认为 SignInManager.SignInAsync 行即使通过密码更改(来自 )也会使用户的会话继续进行,但它似乎由 validateInterval 参数额外控制。

如果我想允许用户在经过身份验证的会话期间更改他们的密码而不强制然后再次登录,我可以使用 ASP.NET 身份执行此操作并仍然控制多个活动会话吗?有没有更好的方法来控制多个活动会话而不更改 validateInterval 参数(来自 )?

感谢您的帮助。澄清一下,如果这种行为是设计使然,我可以接受。我只是想了解发生了什么,这样我就可以在需要时为我的老板辩护。

编辑:

我没有提到我还在登录操作中通过 SignInManager 直接更新安全标记。

做你正在做的事情并不会阻止多个活动会话。我还假设 "sessions" 您是在谈论同一用户帐户的多次身份验证。多个活动会话,在最真实的意义上,是一个完全不同的讨论。也就是说,为保持用户 "authenticated" 状态而设置的 cookie 是 client-specific。如果我从台式计算机和移动设备登录,甚至从同一台计算机上的 Chrome 和 Internet Explorer 登录,这些都是不同的 cookie,不受可能已在其他设备上设置的其他 cookie 的影响或浏览器。

唯一可以真正防止这种情况的方法是以某种方式将用户标记为 "logged in" server-side(例如,您的用户 table 上的一列)。然后,在其他任何地方对他们进行身份验证之前(基本上是在您的登录 post 操作中),您将检查他们的用户帐户是否有此标志。如果已经设置,那么您将拒绝他们再次登录,直到他们首先在原始 device/browser 上注销。显然,您的注销操作必须取消设置此标志,这样他们才能在其他地方再次登录。