This commit removes the now defunkt `ErrorAttributes.ERROR_ATTRIBUTE`
that was introduce to register handled errors as metrics. This has been
replaced since 3.0 by a direct support in Spring Framework and had no
effect whatsoever since that release.
This also updates the documentation to point to the Framework mechanism
that replaced it.
Fixes gh-33731
There are some notable differences in the behavior of Spring
Security's reactive and servlet-based web security. Notably,
Servlet-based web security (`@EnableWebSecurity`) works without
any authentication manager, rejecting requests as not authorized.
By contrast reactive-based web security (`@EnableWebFluxSecurity`)
fails to start up when there's no authentication manager, either
provided directly as a bean or derived from a
ReactiveUserDetailsService. There are also further differences at
runtime where empty Monos from all ReactiveAuthenticationManagers
results in an internal error and a 500 response whereas a similar
situation in the servlet implementation results in a 401.
Previously, to accommodate these differences in behavior, Spring
Boot's auto-configuration would behave differently. In the Servlet
case, web security would be enabled whenever the necessary
dependencies were on the classpath. In the reactive case, web
security would back off in the absence of an authentication manager
to prevent a start up failure. While this difference is rooted in
Spring Security, it is undesirable and something that we want to
avoid Spring Boot users being exposed to where possible.
Unfortunately, the situation is more likely to occur than before
as ReactiveUserDetailsServiceAutoConfiguration now backs off more
readily (gh-35338). This makes it more likely that the context will
contain neither a reactive authetication manager not a reactive
user details service.
This commit reworks the auto-configurations related to reactive
security. ReactiveSecurityAutoConfiguration will now auto-configure
an "empty" reactive authentication manager that denies access through
Mono.error in the absence of a ReactiveAuthenticationManager,
ReactiveUserDetailsService, or SecurityWebFilterChain. The last of
these is to allow for the situation where a filter chain has been
defined with an authentication manager configured directly on it.
This configuration of an authentication manager allows
`@EnableWebFluxSecurity` to be auto-configured more readily,
removing one of the differences between reactive- and Servlet-based
security.
Corresponding updates to the auto-configurations for reactive OAuth2
support have also been made. They no longer try to auto-configure
`@EnableWebFluxSecurity`, relying instead upon
ReactiveSecurityAutoConfiguration, which they are ordered before, to
do that instead.
Closes gh-38713
