Add 'filterChainMatcher' as an alias of 'requestMatcher'

[akuma8]

When configuring security rules, it will be very helpful to understand what we are configuring. Example with this kind of configuration :

@Configuration
public class UIResourceProtection extends WebSecurityConfigurerAdapter {

    @Override
    public void configure( HttpSecurity http ) throws Exception {

        http.requestMatchers().antMatchers("/product/**") // be more explicit here 
                .and()
                .authorizeRequests()
                .antMatchers(HttpMethod.PATCH,"/product/update")
                .hasRole("user")
                .antMatchers("/product/private/**").hasRole("super_user")
                .and()
                .oauth2ResourceServer()
                .jwt().jwtAuthenticationConverter( ... ) ;
    }
}

To help beginners to understand what they are doing, it will be helpful to name explicitly what we configure:

@Configuration
public class UIResourceProtection extends WebSecurityConfigurerAdapter {

    @Override
    public void configure( HttpSecurity http ) throws Exception {

        http.filterChainMatchers().antMatchers("/product/**") // with this "filterChainMatchers()" alias we know that we are defining the filter chain selector and its more explicit.
                .and()
                .authorizeRequests()
                .antMatchers(HttpMethod.PATCH,"/product/update")
                .hasRole("user")
                .antMatchers("/product/private/**").hasRole("super_user")
                .and()
                .oauth2ResourceServer()
                .jwt().jwtAuthenticationConverter( ... ) ;
    }
}

Spring Security is not easy to understand, naming things in a clear way could only simplify the life of users, especially beginners.

[rwinch]

Are you speaking about making it more explicit between the matchers on HttpSecurity and the authorization rules?

[akuma8]

Are you speaking about making it more explicit between the matchers on HttpSecurity and the authorization rules?

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.

[rwinch]

I think that makes sense and have thought about it a bit. I'd prefer not exposing implementation details like filterChainMatchers in the DSL. I think something like this would be what I would suggest:

http
    .httpSecurityMatcher(matcher)
    ...

Thoughts?

[akuma8]

I'd prefer not exposing implementation details like filterChainMatchers in the DSL

Is there an abstraction of filter chain? If yes, I thought you are right. In my mind filter chain was a specific Spring Security concept. I know that when chaining multiples servlet filters we can call that filters chain but I think in Spring Security it is a strong concept that is not really highlighted in the configuration.

[rwinch]

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 HttpSecurity in this case. In any case, would you be interested in submitting a PR?

[marcusdacoregio]

Related to https://github.com/spring-projects/spring-security/issues/11347. If we deprecate/remove mvcMatchers, antMatchers, etc. and add requestMatcher variations, it can become confusing for folks that are using the Customizer.

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 Customizer is used, the requestMatcher is repeated multiple times:

http.requestMatchers(customizer -> customizer
    .requestMatcher("/path1/**")
    .requestMatcher("/path2/**")
    .requestMatcher(new AntPathRequestMatcher("..."))
)

This is another point to consider when adding this feature.

[marcusdacoregio]

Maybe the name of the method could be securityMatcher to better align with the Kotlin DSL and Reactive:

http
    .securityMatcher(matcher)
    ...