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>
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>
This commit adds an IllegalStateException guard when spring-security-access
is missing and the application is using @EnableGlobalMethodSecurity with
jsr250Enabled.
Issue gh-19441
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
The "Move Core Access API" refactoring (gh-17847) relocated
MethodSecurityMetadataSourceAdvisor and MethodSecurityInterceptor
from spring-security-core, a mandatory dependency of
spring-security-config, into the new spring-security-access module,
which spring-security-config only depends on optionally.
GlobalMethodSecuritySelector (backing the deprecated
@EnableGlobalMethodSecurity) and ReactiveMethodSecuritySelector
(backing @EnableReactiveMethodSecurity(useAuthorizationManager =
false)) still unconditionally import configuration that constructs
those classes: MethodSecurityMetadataSourceAdvisorRegistrar in proxy
mode, GlobalMethodSecurityConfiguration in both proxy and aspectj
mode, and ReactiveMethodSecurityConfiguration for the legacy reactive
path. Applications that use any of these deprecated configuration
paths without explicitly adding spring-security-access now fail at
startup with a confusing NoClassDefFoundError deep inside Spring's
configuration-processing machinery, instead of an actionable message.
@EnableMethodSecurity and @EnableReactiveMethodSecurity's default
(AuthorizationManager-based) mode, the non-deprecated replacements,
never reference these classes and are unaffected either way.
Add a ClassUtils.isPresent check to both selectors so that, whenever
a legacy configuration path that needs it is chosen (proxy mode,
aspectj mode, or the legacy reactive interceptor), a missing
spring-security-access dependency now fails fast with a clear
IllegalStateException that names the missing dependency and points
to the supported alternative, rather than a NoClassDefFoundError.
This preserves gh-17847's footprint-reduction intent: the check only
runs for the deprecated legacy annotations, so the majority of
applications using @EnableMethodSecurity see no change in behavior or
dependencies. @EnableGlobalMethodSecurity remains deprecated; this
change adds no new investment in it beyond giving existing users of
it a clear diagnostic instead of a confusing crash.
Closes gh-19441
Signed-off-by: jyx-07 <s25069@gsm.hs.kr>
Josh Cummings