-
Couldn't load subscription status.
- Fork 6.2k
Description
Given that TargetVisitor instances are ordered, it's important that applications have a way to clearly indicate whether their TargetVisitor comes before or after Spring Security visitors. With WebTargetVisitor being set to LOWEST_PRECEDENCE, an application cannot guarantee that their visitor would evaluate after WebTargetVisitor, should they want that.
One specific issue can be seen with the following bean declaration:
@Bean
TargetVisitor skipValueTypes() {
return TargetVisitor.defaultsSkipValueTypes();
}Since both this and WebTargetVisitor use LOWEST_PRECEDENCE, Spring cannot guarantee a deterministic ordering. Also, there is no way to guarantee an ordering other than this bean coming before WebTargetVisitor.
If WebTargetVisitor has a precedence of 100, then the above bean definition's intent is clear that it should not override WebTargetVisitor's behavior. It could now also state a precedence of 0, stating that it intends to visit the proxy before WebTargetVisitor does.
Similarly to AuthorizationInterceptorsOrder and FilterOrderRegistration, each Spring Security visitor should have a different value with a reasonable gap in between to simplify placement.
This change should be based on the 6.5.x branch and should include tests that demonstrate that a custom visitor can be published deterministically before or after Spring Security's TargetVisitor implementations.