Expected Behavior

Add a constructor with AuthenticationProvider as a factor to the DaoAuthenticationProvider class

Current Behavior

DaoAuthenticationProvider has a constructor with a passwordEncoder as a factor and a generator with a basic password encoder in a member variable without having anything as a factor.
code

Context
Hello 👋

The official document guides the invocation of DaoAuthenticationProvider's authenticate method through ProviderManager for basic login using an ID password for Spring Security-supported logins. docs
Since these classes provide the necessary functions for basic login, I think they can be used well when customizing logins.

Although the filter may be in charge of logging in, I created and customized a controller in charge of logging in because I valued the hierarchical structure of controllers, services, and repository.

When using DaoAuthenticationProvider, I think the part that should be customized is UserDetailsService. Because the developer must access the space of the desired path and bring user information, UserDetailsService plays this role.
Although there is a built implementation, DB access technology exists only in JDBC in the implementation that accesses the database, and applications accessing the database through ORM technology such as JPA must be customized for the UserDetails Service to use ORM.

Therefore, what I suggest is to add a generator with UserDetailsService as a factor to the creator of DaoAuthenticationProvider.
There is a setUserDetailsService method, but using it creates a situation in which the empty declaration unit has to violate DIP among SOLID principles.
This is because there is no setUserDetailsService method in the AuthenticationProvider interface, so when declaring a type, the implementation, DaoAuthenticationProvider, must be established as a type and started.

• Current code violating DIP principles
  

• I hope it passes
  

• Code I want to add