Избегайте сброса AccessFailedCount с помощью CheckPasswordSignIn в ASP.Net Identity
Это моя программа.cs:
//Options For Identity
opt.Lockout.AllowedForNewUsers = true; //True Bcz I want Active For All Users
opt.Lockout.DefaultLockoutTimeSpan = new TimeSpan(100, 1, 1, 1); //Its Like Ban For Ever
opt.Lockout.MaxFailedAccessAttempts = 10; //Just Admin Can Increase This For Users
И это мое действие при входе в систему для аутентификации:
Check Username ->
_signInManager.UserManager.FindByNameAsync(model.Username);
Check Password ->
_signInManager.CheckPasswordSignInAsync(userId, Password, False)
//False Because I dont Want Increse AccessFailedCount In database for Wrong Passwords
Теперь, если администратор хочет сообщить о пользователе (UserId), это произойдет:
_userManager.AccessFailedAsync(UserId); //Its Like Increase +1 AccessFailedCount In DataBase
Итак, теперь я ожидаю, что если администратор сообщит о пользователе 10 раз -> пользователь будет забанен навсегда.
Но проблема в следующем: если пользователь войдет в мой WebApi -> Этот метод _signInManager.CheckPasswordSignInAsync автоматически сбросит AccessFailedCount на 0 ... :(
Как избежать сброса AccessFailedCount с помощью этого метода после однократного успешного входа пользователя в систему
Пожалуйста, не говорите, что это невозможно... (наконец-то дайте мне новую стратегию) мой API готов, мне нужна экстренная помощь
@VDWWD, ты это имеешь в виду? Class CustomEntity : IdentityUser добавить новую колонку вот так public int MyCount {get;set;} ?
Да что-то подобное. Тогда вы можете иметь обычное количество неудачных попыток для одного входа в систему и общее количество для блокировки пользователя, если это необходимо.
Ответы 1
Я не верю, что можно избежать сброса этого счетчика, однако аналогичного эффекта можно добиться следующим образом:
- Получите AccessFailedAcount из объекта пользователя перед его входом в систему.
- Войдите в систему
- Восстановите AccessFailedCount в объекте пользователя.
- Обновите объект пользователя через UserManager.
Я протестировал приведенный ниже код, который использует немного другой метод входа, чем ваш, но принцип должен быть точно таким же.
//get access failed count
var signinManager = HttpContext.GetOwinContext().GetUserManager<ApplicationSignInManager>();
var user = signinManager.UserManager.Find(model.Email,model.Password);
int AccessFailedCount = user.AccessFailedCount;
//sign user in.
var result = signinManager.PasswordSignIn(user.UserName, model.Password, false, shouldLockout: false);
if (result == SignInStatus.Success)
{
//restore access failed count.
user.AccessFailedCount = AccessFailedCount;
signinManager.UserManager.Update(user);
//redirect away from login page.
}
Боже мой, спасибо, братан... Ты спас мой проект <3... Я хочу принять твой ответ, но перед этим у меня есть вопрос. Я чувствую, что программа может быть прервана в будущем, потому что: await CheckPasswordSignInAsync(reset Count) И UpdateAsync(Change Count) Может ли это вызвать ошибки в будущем?
Я рад, что у тебя все получилось. Либо метод входа signinManager.PasswordSignIn, либо CheckPasswordSignInAsync должен работать нормально. Важной частью является сохранение исходного количества неудачных доступов и возможность обновления объекта пользователя. Они являются стандартными для Identity, поэтому я сомневаюсь, что они сильно изменятся (если вообще изменятся) или вызовут ошибки в будущем.
Отслеживайте неудачные попытки в специальной таблице или столбце и напишите код для обработки этой логики.