Как правильно предотвращать многоразовые активные сеансы в ASP.NET Identity 2.2.1, не влияя на поведение смены пароля?

Question

У меня есть требование устранить несколько активных сеансов, которые разрешены на нашем сайте.

Это мое понимание того, что сделать это можно манипулировать параметр validateInterval свойства OnValidateIdentity в CookieAuthenticationProvider, как показано ниже:

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 секунд, а затем перенаправляется на страницу входа.

Внутри действия ChangePassword класса ManageController код по умолчанию, который запускается после успешной смены пароля заключается в следующем:

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 будет держать сеанс пользователя происходит даже через пароль изменение (от Logout User From all Browser When Password is changed), но, похоже, оно дополнительно контролируется параметром validateInterval.

Если я хотел разрешить пользователю изменять свой пароль во время аутентифицированного сеанса без принуждения, а затем снова войти в систему, смогу ли я сделать это с помощью идентификатора ASP.NET и по-прежнему контролировать несколько активных сеансов? Есть ли лучший способ контролировать несколько активных сеансов без изменения параметра validateInterval (от Prevent multiple logins)?

Благодарим за помощь. Чтобы уточнить, если это поведение по дизайну, я в порядке с ним. Я просто хочу понять, что происходит, поэтому я могу защитить поведение своего босса, если это необходимо.

Edit:

я не упомянул, что я также обновить штамп безопасности непосредственно до знака через SignInManager в Вход действия.

Answer 1

Выполнение того, что вы делаете, не мешает нескольким активным сеансам. Я также предполагаю, что «сеансы» вы говорите о нескольких аутентификации одной и той же учетной записью пользователя. Несколько активных сеансов в прямом смысле - это совсем другое обсуждение. Тем не менее, cookie, настроенный на поддержание «аутентифицированного» состояния пользователя, зависит от клиента. Если я вхожу в систему с моего настольного компьютера и с моего мобильного устройства или даже из браузера Chrome и Internet Explorer на том же компьютере, это все разные куки-файлы, на которые не повлияли другие файлы cookie, которые могли быть установлены на других устройствах или в браузерах.

Единственный способ, которым вы действительно могли бы предотвратить это, - это как-то пометить пользователя как «вошедшего в систему» ​​на стороне сервера (т. Е. Столбца вашей таблицы пользователей, например). Затем перед их аутентификацией в другом месте (в основном в вашем знаке после действия) вы должны проверить свою учетную запись для этого флага. Если он уже установлен, вы отказываетесь регистрировать их снова, пока они не выйдут на исходное устройство/браузер.Очевидно, что ваше действие выхода из системы должно было бы затем отключить этот флаг, поэтому им будет разрешено снова войти в систему в другом месте.