Luke Taylor (Migrated from SEC-1495) said:
The most important use case when using a principal object such as a UserDetails object as a key for a lookup is that two objects which represent the same user should be equal. A key example is the SessionRegistry. The current User class builds the hashcode and equals using all the data in the object, which means that if the user data is modified, and the user then attempts to log in again, they will be allowed to because the principal object is not the same for the second login, so will not appear to be registered.
The User object should just use the username when calculating the hashcode and for equality checks (this should be documented).
This is also related to SEC-1493, in that the user object may change once it has been loaded. The credentials should not be part of the hashcode calculation either.
Luke Taylor said:
I've converted the User class to only make use of the username property in the equals and hashcode methods