Verify that <cors> detects a PreFlightRequestHandler bean and uses a
PreFlightRequestFilter when no explicit ref or
configuration-source-ref is given and no mvcHandlerMappingIntrospector
bean is present.
See gh-19542
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
Spring Framework 7.1 deprecates RestTemplate and related types for
removal. Suppress the resulting warnings at existing internal usage
sites until they are migrated to RestClient per gh-19027.
Closes gh-19544
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
Spring Framework 7.1 removes HandlerMappingIntrospector-derived
implicit CORS handling for plain requests; these tests assert the
old behavior.
Closes gh-19543
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
Add CorsFilterFactoryBean so the <cors> XML element can detect a
CorsConfigurationSource or PreFlightRequestHandler bean implicitly,
matching CorsConfigurer's existing Java config behavior.
Closes gh-19542
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>
A published PathPatternRequestMatcher.Builder bean is intended to align
application endpoint matchers, which commonly are from the same servlet.
This commit ensures that this bean is used by securityMatcher(s),
authorizeHttpRequests, and WebSecurity#ignoring, which target
application endpoints typically served by servlets.
This commit also adds tests ensuring that the bean is not applied to filter-chain
security endpoints such as those configured by formLogin, logout,
oneTimeTokenLogin, OAuth 2.0 Login, and SAML 2.0 Login, since
these endpoints are, by default, handled by filters independent from
any target servlet and servlet path.
Closes gh-19128
Signed-off-by: Josh Cummings <3627351+jzheaux@users.noreply.github.com>
Add CredentialRecordOwnerAuthorizationManager that verifies the
credential being deleted is owned by the currently authenticated user.
Also add an AuthorizationManager<Bytes> to WebAuthnRegistrationFilter
for the delete credential operation, defaulting to deny all, and wire it
up in WebAuthnConfigurer.
Per the WebAuthn specification [1], credential ids contain at least 16
bytes with at least 100 bits of entropy, making them practically
unguessable. The specification also advises that credential ids should
be kept private, as exposing them can leak personally identifying
information [2]. The CredentialRecordOwnerAuthorizationManager serves as
defense in depth: even if a credential id were somehow exposed, an
unauthorized user could not delete another user's credential.
[1] https://www.w3.org/TR/webauthn-3/#credential-id
[2] https://www.w3.org/TR/webauthn-3/#sctn-credential-id-privacy-leak
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>
Joe Grandja