[Bug]: Resetting password after user action lockout does not reset failed login attempts

[JoshTheHero]

What happened?

After a password reset for a user that is locked out(via user action due to failed attempts), the failed login attempts counter is not reset. Essentially if a user resets the password but still types in the wrong password on the next attempt, they will be locked out again. I would expect that failed login counter to be reset after a reset password flow. Seems to be the same issue as #1394 which was fixed in 1.42.0, so this must be some sort of regression.

Reproduction steps:

1. Configure user action on failed login attempts to lockout user
2. Set up user action on Tenant after user tries to log in 5 times in 1 minute(or however many attempts in X time). Make sure "Cancel Action on Password Reset" is enabled.
3. Trigger that lockout for a user
4. Reset password for locked out user. They are no longer locked out but if the user mistypes the new password after the reset, they are immediately locked out again since they are still in the original time frame of the initial lockout.

Version

1.53.2

Affects Versions

No response

[robotdan]

Not sure this is a bug, but perhaps it could be confusing?

So the use case is:

1. The user gets locked out of their account.
2. The user resets their password - we cancel the action to unlock their account.
3. The user user enters the password incorrectly again within the configured time period
4. The user gets locked again.

Seems reasonable that we reset the failed login attempts to 0 after a reset - but in most cases - at least in an ideal case, the user is logged in automatically after a password change, so the user would then need to log out, or authenticate somewhere else and enter the password incorrectly within the same configured time window to trigger this lock.

Does that sound correct?

[JoshTheHero]

Yes that is correct. I labeled it a bug because it had been fixed with 1.42.0 according to #1394 and now it no longer works in 1.53.2. If it's not a bug, does that mean this design choice has been walked back intentionally after implementing it? Seems odd to go through the work of implementing this change previously at a customer's request then to change it back afterwards(I also did not see anything in the release notes since 1.42.0 regarding this).