In other extensions of `AbstractAuthenticationToken`, the constructors
that include `authorities` call `setAuthenticated(true)`. This includes
`PreAuthenticated`-, `UsernamePassword`-, and
`RememberMeAuthenticationToken`.
This change brings `TestingAuthenticationToken` in line with that
convention.
Note that this was done once already to one of the constructors
(ee13be4) in `TestingAuthenticationToken` that takes an arity of
`authorities`. It was not propagated to the constructor that takes a
collection, which is what this commit remedies.
Fixes: gh-5073
Instead of copying classes to the compile output, we now add them directly to the JAR.
This allows JavaCompile to be cached, since there are no overlapping outputs anymore.
Update `DaoAuthenticationProvider` so that `userNotFoundEncodedPassword`
is lazily initialized on the first call to `retrieveUser`, rather than
in `doAfterPropertiesSet`.
Since some `PasswordEncoder` implementations can be slow, this change
can help to improve application startup times and the expense of some
delay with the first login.
Note that `userNotFoundEncodedPassword` creation occurs on the first
user retrieval, regardless of whether the user is ultimately found. This
ensures consistent processing times, regardless of the outcome.
First Call:
Found = encode(userNotFound) + decode(supplied)
Not-Found = encode(userNotFound) + decode(userNotFound)
Subsequent Call:
Found = decode(supplied)
Not-Found = decode(userNotFound)
Fixes gh-4915
As principals and sessionIds are set in class itself so one can't share user session count across nodes(Cluster). Using constructor for setting principals and sessionIds we can pass Cache map to constructor which can enable common session count in cluster otherwise user would be allowed to logged in with multiple sessions. There is no point keeping principals and sessionIds completely internal.
When the principal of the Authentication is an object, it is not necessarily
an User: it could be another implementation of UserDetails, or even a
completely unrelated type. Since the type of the object is serialized as a
property and used by the deserialization anyway, there's no point in
enforcing a stricter type.
Not only is it more efficient without converting to an intermediate String,
using JsonNode.toString() may not even produce valid JSON according to its
Javadoc (ObjectMapper.writeValueAsString() should be used).
Rob Winch
Josh Cummings
ylombardi
Joe Grandja
Johnny Lim
Lóránt Pintér
Phillip Webb
Chris Burrell
Oleg Zhuravlev
Benedikt Ritter
Greg Turnquist
Gajendra kumar
Frank Pavageau
Antoine