Description
Symfony version(s) affected
5.4.21+
Description
When using the 'hide_user_not_found' feature (enabled by default), a user who tries to login with the proper credentials and has a locked or disabled account, will receive the "Invalid credentials" message. This is unexpected as the user is found, but the account is locked or disabled. The exception thrown for these cases are either the LockedException, DisabledException, or AccountExpiredException. One would expect this message only for a UsernameNotFoundException, not including cases where the user is found, but is inactive or locked out in some way. This used to provide useful feedback for our clients so they would not waste time trying to reset their password. I guess some could argue it is better to obfuscate the error in all cases, but this seems a bit paranoid, and again the feature seems improperly named. I would propose to either rename this or better yet, separate this into two features: e.g. hideUserNotFoundExceptions and hideAllAuthExceptions.
How to reproduce
Setup the application as normal. Implement a UserCheckerInterface on the main secured firewall. Throw an AccountStatusException in the checkPostAuth function. The exception can be the LockedException, DisabledException, or AccountExpiredException. Notice the message to the user is "Invalid (or Bad) credentials".
Possible Solution
Looking at the code in AuthenticatorManager#handleAuthenticationFailure:271 it does seem like a bug or at least a feature with a misleading name: hideUserNotFoundExceptions.
Replacing that conditional block with this made it work as expected and as previously:
if ($this->hideUserNotFoundExceptions && ($authenticationException instanceof UsernameNotFoundException
|| $authenticationException instanceof UserNotFoundException)) {
$authenticationException = new BadCredentialsException('Bad credentials.', 0, $authenticationException);
}
I believe this block of code is also in a few other classes in the codebase, so this would also would be nice to address.
This is similar to this previously discussed here #42793, but has already been closed.
Additional Context
No response