You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To configure which observations Security should make, it's needed to provide an ObservationPredicate. For example, in a boot application you can disable all security observations like so:
This may feel counter-intuitive and there is thus a temptation to do (name, context) -> name.startsWith("spring.security.*") which instead would turn off all observations application-wide, except for the Spring Security observations.
Also, an application could reasonably want to turn off the filter chain observations while leaving the authentication and authorization observations intact, and it is cumbersome to require an application to formulate the appropriate logic to honor the various observation names.
One way to simplify this would be to publish a defaults object:
HttpSecurity and @EnableMethodSecurity could optionally depend on this bean and apply the correct ObservationWebFilterDecorator, ObservationAuthenticationManager, and ObservationAuthorizationManager instances accordingly.
The nice thing about this approach is that Spring Security could avoid wrapping the filter chain, authentications, and authorizations in more situations, improving runtime performance.
Finally, this allows us to better articulate a change to the defaults in future major versions of Spring Security, for example by leaving a subset of the observations off by default, something that has been requested in spring-projects/spring-boot#34133
The text was updated successfully, but these errors were encountered:
To configure which observations Security should make, it's needed to provide an
ObservationPredicate
. For example, in a boot application you can disable all security observations like so:This may feel counter-intuitive and there is thus a temptation to do
(name, context) -> name.startsWith("spring.security.*")
which instead would turn off all observations application-wide, except for the Spring Security observations.Also, an application could reasonably want to turn off the filter chain observations while leaving the authentication and authorization observations intact, and it is cumbersome to require an application to formulate the appropriate logic to honor the various observation names.
One way to simplify this would be to publish a defaults object:
HttpSecurity
and@EnableMethodSecurity
could optionally depend on this bean and apply the correctObservationWebFilterDecorator
,ObservationAuthenticationManager
, andObservationAuthorizationManager
instances accordingly.The nice thing about this approach is that Spring Security could avoid wrapping the filter chain, authentications, and authorizations in more situations, improving runtime performance.
Finally, this allows us to better articulate a change to the defaults in future major versions of Spring Security, for example by leaving a subset of the observations off by default, something that has been requested in spring-projects/spring-boot#34133
The text was updated successfully, but these errors were encountered: