cleaning up our custom implementation of UserDetails based on the User implementation, I noticed that User throws an error if password is null in the constructor. The documentation doesn't mention that it must be non null (and as previously mentioned no decorators saying this), more especially I don't understand why given that it can be set to null later and there are use cases where setting it to null shouldn't matter.
Comment From: jzheaux
Thanks for reaching out, @xenoterracide. The reason password must not be null is that Spring Security verifies the password. It's easier to check for null once when User is created than to check with each getPassword call. The use cases that User is intended for are when there's a password for Spring Security to verify.
It feels like this is a question that would be better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. If my answer above isn't sufficient, feel free to post a link to the corresponding SO question, and we can continue over there.
Comment From: xenoterracide
I consider it a documentation bug, I couldn't find it documented anywhere, IIRC including the javadoc, and since you can instantiate a User for something unrelated to authentication, or even presumably for an authentication method that doesn't use a password, it doesn't make much sense.
Comment From: jzheaux
Good points, @xenoterracide, it sounds like there's value in updating UserDetails to clarify that it fits best with local authentication use cases.
or even presumably for an authentication method that doesn't use a password
UserDetails is intended for password-based authentication strategies. You'll notice, for example, that Spring Security's OAuth 2.0 support uses different principals, like OAuth2User and Jwt instead of a UserDetails.
you can instantiate a User for something unrelated to authentication
Yes, this is hypothetically possible, though I find that most applications find greater flexibility in having their own entirely independent representation of the user.
Comment From: xenoterracide
yes, we do, I was trying to use User when writing for mockmvc, and came across this (among other things), and I was surprised, because I wasn't actually authenticating I just needed a fully authenticated session (or so I thought), hence no need for a password.
Comment From: jzheaux
Great, @xenoterracide, thanks for the clarification. Do you have any suggestions on how the documentation ought to change?
I don't think that User's documentation should change for the sake of testing -- it's quite common to need to mock information in a test, and it actually sounds like you don't need an instance of User for your tests anyway.
However, I can see it would be helpful to add a sentence in UserDetails's JavaDocs indicating that it's intended for local authentication scenarios.