Hello, we are currently updating our ASPNETZERO-based application to use the ASP.NET Boilerplate v9.4.0 packages. During the testing phase, we have noticed unusual and incorrect lockouts for our test-users. Looking at this change it seems that, despite a user being successfully authenticated and logged in with AbpLoginResultType.Success, the lock-out and access-failed logic is always executed.

We are calling the LoginAsync(UserLoginInfo login, string tenancyName = null, bool shouldLockout = true) with shouldLockout=true, but if I understand correctly, this parameter is only intended to indicate whether user-lockout is enabled at application/tenant level.

Could this be a bug in the logic, or am I misinterpreting this code? (line 110 and 131 of the AbpLoginManager classes)

Hi @wv-lennic

This issue will be resolved when you update the ASP.NET Boilerplate packages to version v9.4.2.

Hi @oguzhanagir

Wow, thank you for your quick reply. 👍

I have looked at the changes for the AbpLoginManager in tag v.9.4.2, and think you are referring to commit 10cede2?

Although this is a change in the same class, it seems to be a change in the other LoginAsync method (username and password as parameter). I am using the LoginAsync that has a UserLoginInfo parameter.

If I am interpreting the code correctly, the issue seems to be in the underlying LoginAsyncInternal method, that always executes TryLockOutAsync, if shouldLockout is true.

My apologies if this is not the correct way to address this problem. I was looking at the code and thought it might be of help to pinpoint to the problem. If you would prefer I create an issue, I can do so.

Hi @wv-lennic

If the purpose here is to lock the user, the shouldLockout value is true. The TryLockOutAsync method locks the user using the current user's information together with UnitOfWorkManager. It is necessary to check in this way because whether the user should be locked out is determined by different operations. When the host is active, the user can be locked out. shouldLockout can be either false or true. This value does not depend on the setting's active state

Hi @oguzhanagir

Thank you for the explanation, but I am still a bit confused. If I take a look at the TokenAuthController and AccountController of the aspnetzero repository, the value of shouldLockout is based on the setting AbpZeroSettingNames.UserManagement.UserLockOut.IsEnabled.

I understand that the TryLockOutAsync itself does not determine whether the user should be locked and that it should be determined at a higher level. But the LoginAsyncInternal with username/password only calls this method if CheckPasswordAsync returns false (using GetFailedPasswordValidationAsLoginResultAsync), while the LoginAsyncInternal with UserLoginInfo seems to always call this method.

Am I missing something here?

Hi @wv-lennic

Yes, you are right, if shouldLockout setting is active, it will be true. You've made a good point. The TryLockOutAsync method itself doesn't decide whether the user should be locked out—it’s controlled by the higher-level methods that call it. You’ve highlighted the difference between the two login flows:

For username/password logins, TryLockOutAsync is only called if CheckPasswordAsync fails. This makes sense since failed password attempts can lead to a lockout.
For external logins (e.g., using UserLoginInfo), TryLockOutAsync is called every time, regardless of success or failure.

It would be logical to call the TryLockOutAsync method for users logging in with UserLoginInfo only after checking for failed login attempts, just like it's done in password-based logins.

I have created an issue for this, and you can follow the updates from there.

Thank You

That's great news, thank's for looking into it so fast!
I will follow the updates from there. 👍