- Changed annotation property to useAuthorizationManager
to match related XML support
- Moved support found in bean post-processors back into
interceptors directly. This reduces the number of components to
maintain and simplifies ongoing support
- Added @Deprecated annotation to indicate that applications
should use AuthorizationManagerBeforeReactiveMethodInterceptor and
AuthorizationManagerAfterReactiveMethodInterceptor instead. While
true that the new support does not support coroutines, the existing
coroutine support is problematic since it cannot be reliably paired
with other method interceptors
- Moved expression handler configuration to the constructors
- Constrain all method security interceptors to require publisher types
- Use ReactiveAdapter to check for single-value types as well
Issue gh-9401
Polish
Prior to this, the HttpSecurity bean was not consistent with WebSecurityConfigurerAdapter's HttpSecurity because it did not setup a default AuthenticationEventPublisher. This also fixes a problem where the AuthenticationEventPublisher bean would only be considered if there was a UserDetailsService
Closes gh-11449
Closes gh-11726
Prior to this, the HttpSecurity bean was not consistent with WebSecurityConfigurerAdapter's HttpSecurity because it did not setup a default AuthenticationEventPublisher. This also fixes a problem where the AuthenticationEventPublisher bean would only be considered if there was a UserDetailsService
Closes gh-11449
Closes gh-11726
Previously the CsrfToken was set on the request attribute with the name
equal to CsrfToken.getParameterName(). This didn't really make a lot of
sense because the CsrfToken.getParameterName() is intended to be used as
the HTTP parameter that the CSRF token was provided. What's more is it
meant that the CsrfToken needed to be read for every request to place it
as an HttpServletRequestAttribute. This causes unnecessary HttpSession
access which can decrease performance for applications.
This commit allows setting CsrfFilter.csrfReqeustAttributeName to
remove the dual purposing of CsrfToken.parameterName and to allow deferal
of reading the CsrfToken to prevent unnecessary HttpSession access.
Issue gh-11699
Previously the CsrfToken was set on the request attribute with the name
equal to CsrfToken.getParameterName(). This didn't really make a lot of
sense because the CsrfToken.getParameterName() is intended to be used as
the HTTP parameter that the CSRF token was provided. What's more is it
meant that the CsrfToken needed to be read for every request to place it
as an HttpServletRequestAttribute. This causes unnecessary HttpSession
access which can decrease performance for applications.
This commit allows setting CsrfFilter.csrfReqeustAttributeName to
remove the dual purposing of CsrfToken.parameterName and to allow deferal
of reading the CsrfToken to prevent unnecessary HttpSession access.
Issue gh-11699
This removes `@Configuration` from all `@Enable` Annotations and explicitly
adds `@Configuration` to wherever the `@Enable*` Annotations are used.
Closes gh-11653
The default redirect strategy will provide authorization redirect
URI within HTTP 302 response Location header.
Allowing the configuration of custom redirect strategy will provide
an option for the clients to obtain the authorization URI from e.g.
HTTP response body as JSON payload, without a need to handle
automatic redirection initiated by the HTTP Location header.
Closes gh-11373
The default redirect strategy will provide authorization redirect
URI within HTTP 302 response Location header.
Allowing the configuration of custom redirect strategy will provide
an option for the clients to obtain the authorization URI from e.g.
HTTP response body as JSON payload, without a need to handle
automatic redirection initiated by the HTTP Location header.
Closes gh-11373
Before, Spring Security's @Enable* annotations were meta-annotated with @Configuration.
While convenient, this is not consistent with the rest of the Spring projects and most notably
Spring Framework's @Enable annotations. Additionally, the introduction of support for
@Configuration(proxyBeanMethods=false) in Spring Framework provides a compelling reason to
remove @Configuration meta-annotation from Spring Security's @Enable annotations and allow
users to opt into their preferred configuration mode.
Closes gh-6613
Signed-off-by: Joshua Sattler <joshua.sattler@mailbox.org>
