Compare OAuth2AccessToken.TokenType using equals() instead of == in
BearerTokenAuthentication, since TokenType instances are not
guaranteed to be singletons and reference comparison can incorrectly
reject an otherwise-equal bearer token.
Closes gh-19377
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
This commit separates AesBytesEncryptor into two separate
implememtations, allowing for a migration away from default
arrangements that used a null IV
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
This commit adds equals and hashCode implementations as well
as a readResolve implementation to ensure that deserialization
mechanisms can correctly assess the equality of a constnat
and a corresponding deserialized instance. For defense-in-depth
reasons, this commit also favors .equals over == for these
constants.
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
This commit updates password encoders to use a
constant-time comparison method to defend against
timing attacks
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
This commit adds a constant-time equals method,
useful for comparing password hashes or other
sensitive material
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>
Replace deprecated `UriComponentsBuilder` usage and renamed
`oneTimeTokenLogin` DSL method references in the docs with their
current equivalents.
Closes gh-18367
Signed-off-by: Arz Meow <arthur37231@gmail.com>
The proxy server section pointed at RFC 7239 and then told the reader to
configure the application server for the X-Forwarded headers, conflating
the standard Forwarded header with the non-standard X-Forwarded-* set.
Describe the two kinds of headers separately, note that most proxies send
X-Forwarded-* while Spring Framework and servers such as Reactor Netty and
Jetty understand both, and state that the edge proxy has to drop or
overwrite untrusted values for both kinds rather than only one.
Closes gh-19461
Signed-off-by: Sumit Kumar Das <skdas5405@gmail.com>
NimbusJwtDecoder's default RestOperations now respects the JDK's
sun.net.client.defaultConnectTimeout/defaultReadTimeout system properties,
falling back to 30 seconds instead of the previous 500 milliseconds,
matching JwtDecoderProviderConfigurationUtils's existing behavior.
Also documents this default and the RestOperations override in the
reference guide and migration guide (the reference guide's existing
"Configuring Timeouts" section already claimed 30 seconds -- it's been
inaccurate since the 500ms default shipped and is now correct again), and
documents providing a custom JwtDecoderFactory<ClientRegistration> for
OAuth2 Login's ID Token decoding.
Issue gh-19474
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
dependabot[bot]