Add another loadUser method for UserDetailsService to takes Long as its argument about spring-security HOT 5 CLOSED

I want to work on this issue. Could you please let me know what is the motivation behind this overload?

from spring-security.

HI @jtroussard, can you elaborate more on why do you need that? I'm assuming that you are associating ids to your users and want to load them using that id, if so, this is a specific use-case and that is not something that the framework can do for you, since different applications will have different business needs.

from spring-security.

Yup Sorry! @marcusdacoregio I had this all written up and didn't hit the submit button:

Hi Team

I'm still relatively new to the spring/spring-boot world. I'm working on a web applications authentication/access control workflow and was curious about this class.

If our application doesn't have unique username, this makes implementing this method, tricky or impossible.

Does it make sense to add another method to access the target user, with perhaps a signature like this?

Originally I had user by ID, obviously that was an oversight on my part, I wanted user by email.

public UserDetails loadUserById(Long memberId) throws UsernameNotFoundException

public UserDetails loadUserByEmail(String email) throws UsernameNotFoundException

Seems like it wouldn't be a far fetched thought to consider username names don't HAVE to be unique, so now I'm second guessing myself and might be misunderstanding this class and the best practices for user access (to a dynamic account page for example) and authentication.

from spring-security.

What prevents you from implementing the UserDetailsService.findByUsername but passing the emailaddress. The username here is more or less the identifying username you fill into the login name for the authentication (or extract from a token etc.). So it doesn't have to map to a username property in your user table/entity but can map to anything.

from spring-security.

@mdeinum is right. Usually you would pass the email as the username parameter. If it doesn't satisfy your needs, consider implementing your own AuthenticationProvider that does not depend on a UserDetailsService.

I'll close this since there is another alternatives to satisfy your need and I don't feel that the framework should do anything different here.

from spring-security.