`SecurityContextHolderThreadLocalAccessor` currently propagates the
same `SecurityContext` to other threads when Micrometer
Context Propagation is used. This leads to unintended sharing of
mutable state and can cause authentication to leak between threads.
This change updates the accessor to create a new
`SecurityContext` for the target thread while reusing only the
`Authentication` value. Each thread now receives its own
`SecurityContext` instance, preventing cross-thread interference and
aligning with recommended `SecurityContext` usage.
Signed-off-by: Tadaya Tsuyukubo <tadaya@ttddyy.net>
The null check in setPostAuthenticationChecks of
AbstractUserDetailsReactiveAuthenticationManager asserted the current
field value, which is initialized to a default and can never be null,
instead of the method parameter. As a result, null was silently
accepted and the next authenticate call failed with a raw
NullPointerException instead of failing fast with a clear message.
Closes gh-19276
Signed-off-by: dae won <eodnjs01477@gmail.com>
InMemoryUserDetailsManager keys its user map on the lower-cased
username everywhere except changePassword, which looked the current
user up with the raw name. A user whose username contains uppercase
letters could therefore not change its password. Lower-case the
lookup key to match the rest of the class.
Closes gh-19336
Signed-off-by: junhyeong9812 <pickjog@gmail.com>
StandardEvaluationContext.setBeanResolver now accepts a nullable
BeanResolver, so the workarounds added for the original limitation
are no longer needed. This removes the explicit null guards (and
equivalent Optional.ofNullable idiom) as well as the
@SuppressWarnings("NullAway") annotations introduced to silence
the false positives.
In addition to the seven sites that explicitly referenced
spring-projects/spring-framework#35371, two sites in
spring-security-core followed the same workaround pattern without
the comment marker (AbstractSecurityExpressionHandler and
DefaultMethodSecurityExpressionHandler) and have also been
simplified.
Closes gh-17816
Signed-off-by: Kim Tae Eun <snowykte0426@naver.com>
After adding jspecify support in the module that contains the
DaoAuthenticationProvider class, we actually changed the contract logic,
which is a good thing, and this commit fixes it.
Closes: gh-18781
Signed-off-by: Andrey Litvitski <andrey1010102008@gmail.com>
- Fix checkstyle
- Fix the test to use Collection that throws NullPointerException on .contains(null) to replicate the reported issue
Closes gh-18544
Signed-off-by: Robert Winch <362503+rwinch@users.noreply.github.com>
1. Removed comment about not changing field name in a
serialized object as this is true for all fields in a
Java-serialize POJO
2. Added example value for the constructor that demonstrates
the relationship between a role and an authority
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
1. Add Javadoc to state that role is prefixed.
2. Rename constructor argument from `role` to `authority` for better readability.
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
This commit does not cover webauthn which is a special case (uses
jackson sub-package for Jackson 2 support) which will be handled in
a distinct commit.
See gh-17832
Signed-off-by: Sébastien Deleuze <sdeleuze@users.noreply.github.com>
This commit adds support for Jackson 3 which has the following
major differences with the Jackson 2 one:
- jackson subpackage instead of jackson2
- Jackson type prefix instead of Jackson2
- JsonMapper instead of ObjectMapper
- For configuration, JsonMapper.Builder instead of ObjectMapper
since the latter is now immutable
- Remove custom support for unmodifiable collections
- Use safe default typing via a PolymorphicTypeValidator
Jackson 3 changes compared to Jackson 2 are documented in
https://cowtowncoder.medium.com/jackson-3-0-0-ga-released-1f669cda529a
and
https://github.com/FasterXML/jackson/blob/main/jackson3/MIGRATING_TO_JACKSON_3.md.
This commit does not cover webauthn which is a special case (uses
jackson sub-package for Jackson 2 support) which will be handled in
a distinct commit.
See gh-17832
Signed-off-by: Sébastien Deleuze <sdeleuze@users.noreply.github.com>
Since RC1 is right around the corner, let's change the API
footprint as little as possible by using reflection to check
if a class has declared toBuilder themselves. If they have, we
can assume that that class's builder will produce that class.
Issue gh-18052
This reverts commit 95644fb73c, reversing
changes made to fbf7bb3be1.
Reverting this commit will allow us more time to
consider the ideal way to add this support to the public API.
Leaving the Builder in Authentication allows
authentication implementations to implement Builder
without needing to implement BuildableAuthentication.
Issue gh-18052
This commit consolidates logic common to applying one
authenticaiton to another. Specifically, it will copy the
authorities in one authentication into the builder instance
of another.
Closes gh-18053
This allows the authorization logic to be relaxed so that if RequiredFactor
only has an authority specified, then the GrantedAuthority can be of any
type.
Closes gh-18031
Previously GrantedAuthorities had an implicit package tangle because it
was located in ~.core and FactorGrantedAuthority is in ~.core.authority
and FactorGrantedAuthority's authority property was implicitly expected
to be constants found in `GrantedAuthorities`.
This commit moves the constants to the FactorGrantedAuthority which
resolves this tangle. It wasn't initially done because
FactorGrantedAuthority did not exist at that time.
Closes gh-18030
Josh Cummings