**Feature summary** (what you would like to be able to do and where):
Instead of showing in checkuser results "Failed to log in" when a failed login attempt is made, show the reason(s) for the failed login attempt. Currently, when someone tries to log in to a locked account the associated action description only says that the login attempt failed even if the password was correct.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Take an example where a sockmaster logs in with a sock that now cannot edit either through being blocked or locked. They then create a new account and proceed to edit using it on the same or very similar IP address (i.e. similar range). A checkuser then checks the new user or associated IP address, and finds the two accounts:
* If the user was only blocked, the login attempt to the already blocked account would be shown as successful in the CU results which means the CU can be sure that the person who logged in had the correct password and thus (unless compromised) was the person who created the account
* If the user was (also) locked, the login attempt fails before the password is checked. The CU results only show that the login attempt failed. The CU cannot know whether the person trying to log in had the correct password, and so cannot be sure that the person who tried to log in then was the person who created the account.
If the Checkuser knows beyond a reasonable doubt that the login attempt was made by the person who created the account, then they can compare this account to the new account to see if they have technical similarities (IP address / User Agent string etc.). If the previously blocked / locked account was a sockpuppet, this may mean that the checkuser can through technical evidence say the new account is a sockpuppet. If the CU log entry only says it was a failed attempt, the checkuser cannot be sure that the login attempt was made to try and joe-job the locked account. Several sockmasters on enwiki will attempt to impersonate other users / sockmasters, and this means the risk of this being the case means the CU cannot say this new account is definitely a sock of the locked account.
If the password was correct, this feature request would mean that the checkuser would be able to see that the password was correct but the login attempt still failed due to the account being locked. Without this feature request being implemented there is no way to know whether the password was correct.
**Benefits** (why should this be implemented?):
Being able to see why a login attempt failed would make the CU results more useful. Furthermore, with the upcoming changes to User Agent strings in Chrome (T242825), the User Agent string / information may become to generic to be able to fingerprint users. At the moment, a User Agent string being the same between the failed login attempt and the creation of the new account is a way to more strongly say that the two accounts could be related. Once / If UA strings become very generic, being able to see off a joe-job attempt would be harder.
**Extended details**
I've had a look at the checkuser extension / central auth extension source code, and think that the way this could be achieved would be to:
* Modify CentralAuthPrimaryAuthenticationProvider.php's beginPrimaryAuthentication() so that the check to see if the account is locked is placed underneath the function call to CentralAuthUser.php's authenticate()
* Modify CentralAuthUser.php's authenticate() so that it can return whether the password was correct and whether the account is locked. This could be done by adding a new possible string return type such as "lockedbadpassword" / "lockedgoodpassword", or even better (but more breaking) by changing the return type to a list of strings with an empty list meaning "ok" and a non-empty list meaning not okay (such as a list of "locked" and "badpassword").
* Modify CentralAuthPrimaryAuthenticationProvider.php's beginPrimaryAuthentication() to return a AuthenticationResponse::fail that indicates the possibly multiple reasons the request failed, which may require modification to AuthenticationResponse to achieve.
* Modify the Checkuser extension Hooks.php function onAuthManagerLoginAuthenticateAudit() to use a message that indicates the reasons for why the login attempt failed. This could be "checkuser-login-failure-badpassword", "checkuser-login-failure-locked-badpassword" "checkuser-login-failure-locked-goodpassword", and "checkuser-login-failure-nouser". The message used would depend on the information from the provided AuthenticationResponse object.