Previously, ExternalInetAddressMatcher treated a null InetAddress
as external by negating InternalInetAddressMatcher's result.
This commit makes ExternalInetAddressMatcher return false for a
null address, so that neither the internal nor the external
matcher classifies an unknown address as a match.
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
This commit updates InternalInetAddressMatcher to check
InetAddress#isAnyLocalAddress in order to catch
additional IP addresses
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
Previously, ExternalInetAddressMatcher treated a null InetAddress
as external by negating InternalInetAddressMatcher's result.
This commit makes ExternalInetAddressMatcher return false for a
null address, so that neither the internal nor the external
matcher classifies an unknown address as a match.
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
`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>
Add the same opt-in UserDetailsChecker support to
OneTimeTokenReactiveAuthenticationManager, mirroring
OneTimeTokenAuthenticationProvider for the reactive stack.
Issue gh-17655
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
OneTimeTokenAuthenticationProvider no longer validates account status
by default. Applications can opt in via setUserDetailsChecker, for
example by providing AccountStatusUserDetailsChecker to reject locked,
disabled, or expired accounts.
Issue gh-17655
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
The main problem is that OneTimeTokenAuthenticationProvider does not
extend from AbstractUserDetailsAuthenticationProvider, which has a
preauthentication check for user details. However, we do not need to
extend from it because it does not fit the context of the class. In this
regard, I decided to add my own checker to this commit, which performs a
preauthentication check before authorizing the account, similar to how
it is done in AbstractUserDetailsAuthenticationProvider. I also added a
test to OneTimeTokenAuthenticationProviderTests that identifies this
problem.
Closes gh-17655
Signed-off-by: Andrey Litvitski <andrey1010102008@gmail.com>
- Add validation
- Extract to static inner class
- Uniqueness determined by Set rather than requiredFactor
This is important for the failure with the same RequiredFactor, but a
different reason
- Add documentation
Signed-off-by: Robert Winch <362503+rwinch@users.noreply.github.com>
In this commit, we added `@Nullable` to equals methods of classes that
support `jspecify` for consistency with other Spring projects and to
avoid bugs that caused other Spring projects to do this natively.
Closes: gh-18929, gh-18927
Signed-off-by: Andrey Litvitski <andrey1010102008@gmail.com>
- add test for setAuthorizationManagerFactory that is a alternative to setTrustResolver and setDefaultRolePrefix
Closes gh-18412
Signed-off-by: Bae Jihong <dasog@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>
Josh Cummings