-
Notifications
You must be signed in to change notification settings - Fork 6k
Add 'securityMatcher' as an alias of 'requestMatcher' #9159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you speaking about making it more explicit between the matchers on |
Yes, in order to know exactly what we are configuring. Filter chains are the core of authorization rules and currently we do not explicitly know how one is declaratively selected by the framework. By declaratively I mean, by reading the security configuration code, the filter chain matcher should be obvious to us. |
I think that makes sense and have thought about it a bit. I'd prefer not exposing implementation details like
Thoughts? |
Is there an abstraction of filter chain? If yes, I thought you are right. In my mind |
I think my concern is that the DLS tries to hide the implementation details (i.e that FilterChainProxy is used under the covers). Instead, I think it makes more sense to relate the method to the configuration object |
Related to #11347. If we deprecate/remove With the deprecations/removals, instead of doing http.antMatcher("/path/**") We should do: http.requestMatcher("/path/**") This is fine, but it becomes confusing when the http.requestMatchers(customizer -> customizer
.requestMatcher("/path1/**")
.requestMatcher("/path2/**")
.requestMatcher(new AntPathRequestMatcher("..."))
) This is another point to consider when adding this feature. |
Maybe the name of the method could be http
.securityMatcher(matcher)
... |
If Spring MVC is present in the classpath, use MvcRequestMatcher by default. This commit also adds a new securityMatcher method in HttpSecurity Closes spring-projectsgh-11347 Closes spring-projectsgh-9159
When configuring security rules, it will be very helpful to understand what we are configuring.
Example with this kind of configuration :
To help beginners to understand what they are doing, it will be helpful to name explicitly what we configure:
Spring Security is not easy to understand, naming things in a clear way could only simplify the life of users, especially beginners.
The text was updated successfully, but these errors were encountered: