You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It does look for a password encoder and if this one returns null, a new DaoAuthenticationProvider(); is used.
The problem is, that if more than one encoder is in the context, getBeanOrNull(PasswordEncoder.class) does return null too. This is imho unexpected see here
Expected behavior
My expectation would be, that if more than one PasswordEncoder is found, that the context build fails here and issues an error OR tell the user with a WARN message that the first one found is used.
But simple not using any encoder at all, although there are some configured is a problem. The problem was found, because an upstream project used by me configured its own encoder (which is not that easy to discover with component scanning enabled) and I had myself already one configured and wondered, why NO encoder at all was registered on the DaoAuthenticationProvider - a warning or an error would be nice here.
The text was updated successfully, but these errors were encountered:
Hello @tkrah , thank you for the report. I agree, this is surprising behavior.
Unfortunately, we can't afford to make the context build fail in the current 6.x line ; there may be users who do not rely on global authentication and have two password encoders.
While we could add a warning, this means we should probably add a warning for UserDetailsPasswordService and CompromisedPasswordChecker. It also means we would need to consider when users want to silence this warning, as we've had the case recently (gh-15538), which makes the warning more complex.
For now, let's leave this issue open, and see if other users in the community request this too by upvoting the issue.
Hi,
using spring-security 6.3.3 the InitializeUserDetailsBeanManagerConfigurer does have this code:
PasswordEncoder passwordEncoder = getBeanOrNull(PasswordEncoder.class);
It does look for a password encoder and if this one returns null, a
new DaoAuthenticationProvider();
is used.The problem is, that if more than one encoder is in the context,
getBeanOrNull(PasswordEncoder.class)
does return null too. This is imho unexpected see hereExpected behavior
My expectation would be, that if more than one
PasswordEncoder
is found, that the context build fails here and issues an error OR tell the user with a WARN message that the first one found is used.But simple not using any encoder at all, although there are some configured is a problem. The problem was found, because an upstream project used by me configured its own encoder (which is not that easy to discover with component scanning enabled) and I had myself already one configured and wondered, why NO encoder at all was registered on the
DaoAuthenticationProvider
- a warning or an error would be nice here.The text was updated successfully, but these errors were encountered: