-
Notifications
You must be signed in to change notification settings - Fork 6.1k
Description
While clearly different APIs ClientRegistrationRepository
and UserDetailsService
have similar natures in that they take in a likely unique identifier and lookup a record by that identifier.
ClientRegistrationRepository
takes a registration id and returns a ClientRegistration
UserDetailsService
takes a username and returns a UserDetails
InMemoryClientRegistrationRepository
as well as InMemoryReactiveClientRegistrationRepository
both check for duplicates when a list of client registrations is supplied. This is sensible since registration id is semantically a primary key - to have duplicates would be an error.
MapReactiveUserDetailsService
and InMemoryUserDetailsManager
do not check for duplicates though.
This is inconsistent as username is just as unique as a registration id.
This may be tricky to resolve since InMemoryUserDetailsManager
is quite old and it's obvious that there may be applications that rely on the duplicate users being silently resolved through overriding.
Still, this states it for the record so that we can come back to it as opportunities come to light.