Simplify RequestMatcherDelegatingAuthorizationManager.Builder matcher registration

[evgeniycheban]

Simplify RequestMatcherDelegatingAuthorizationManager.Builder matcher registration

Closes gh-11624

[marcusdacoregio]

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?

[marcusdacoregio]

The requestMatchers method should keep the same behavior as AbstractRequestMatcherRegistry by creating a MvcRequestMatcher if possible and use AntPathRequestMatcher as a fallback.

spring-security/config/src/main/java/org/springframework/security/config/annotation/web/AbstractRequestMatcherRegistry.java

Line 181 in 1631cac

public C requestMatchers(HttpMethod method, String... patterns) {

[evgeniycheban]

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?

[marcusdacoregio]

I think you are right, can you make that behavior explicit in the javadoc?

[evgeniycheban]

I've reflected this behavior in the javadoc and updated @since tags to 6.2.

[marcusdacoregio]

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.

[evgeniycheban]

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.

[evgeniycheban]

I've updated the PR.

[marcusdacoregio]

Thanks @evgeniycheban, this is now merged into main