-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Simplify RequestMatcherDelegatingAuthorizationManager.Builder matcher registration #13110
Conversation
dac9fd0
to
652b526
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @evgeniycheban, I have left feedback inline.
Can you please ensure that the @since
tags are updated to 6.2
because we already have a release candidate for 6.1?
* @return the {@link AuthorizedUrl} for further customizations | ||
* @since 6.1 | ||
*/ | ||
public AuthorizedUrl requestMatchers(String... patterns) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requestMatchers
method should keep the same behavior as AbstractRequestMatcherRegistry
by creating a MvcRequestMatcher
if possible and use AntPathRequestMatcher
as a fallback.
Line 181 in 1631cac
public C requestMatchers(HttpMethod method, String... patterns) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @marcusdacoregio, thanks for the review. I'm not sure if it would be a good idea to propagate an ApplicationContext
to this builder, maybe we could create here AntPathRequestMatcher
by default
and let the user register MvcRequestMatcher
using requestMatchers(RequestMatcher... matchers)
.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are right, can you make that behavior explicit in the javadoc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've reflected this behavior in the javadoc and updated @since
tags to 6.2
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @evgeniycheban, I am concerned about having the ant matcher the default if Spring MVC is in the classpath. This deviates from the default that Spring Security adopted in 6.0. For now, what if requestMatchers
only takes a RequestMatcher
instance? We can think more (in another issue) about how to communicate the MVC nuance to the builder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @marcusdacoregio, makes sense, let's stay only with requestMatchers(RequestMatcher... matchers)
for now and think about supporting MvcRequestMatcher
in the future releases. I will update the PR soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the PR.
Thanks @evgeniycheban, this is now merged into |
Simplify RequestMatcherDelegatingAuthorizationManager.Builder matcher registration
Closes gh-11624