For an application to direct Spring Security to use MvcRequestMatcher, it is necessary to use requestMatchers(RequestMatcher...), requiring each request matcher to be constructed by hand.

It may be handy to add authorizeMvcRequests as a convenience method to reduce that boilerplate.

For example, instead of doing:

http
    .authorizeHttpRequests((authorize) -> authorize
        .requestMatchers(new MvcRequestMatcher.Builder(introspector).servletPath("/my-servlet").pattern("/**")).hasAuthority("USER")
        .requestMatchers(new MvcRequestMatcher.Builder(introspector).pattern("/endpoint/**")).hasAuthority("USER")
    )

an application could do the following:

http
    .authorizeMvcRequests("/my-servlet", (authorize) -> authorize
        .anyRequest().hasAuthority("USER")
    )
    .authorizeMvcRequests((authorize) -> authorize
        .requestMatchers("/endpoint/**").hasAuthority("USER")
    )

In this case, the request matcher registry used would be one that would only have requestMatchers(String...), requestMatchers(HttpMethod), requestMatchers(HttpMethod, String...), and anyRequest(). When the servlet path is supplied, anyRequest() would be scoped to that servlet.

The nice thing about this is it encourages applications that have more than just Spring MVC to separate the rules by servlet path, which is a bit more harmonious with how MvcRequestMatcher performs its pattern matching.

There may be more straightforward ways for an application to describe its intent, and this is a good place to share those.

Comment From: nmck257

Another suggestion under the same title: in the current state, it would be lovely to have an overload of .pattern(String) taking varargs String, similar to requestMatchers(String...)