Make it possible for Spring Security to align with Spring MVC without HandlerMappingIntrospector

[rstoyanchev]

This is already the case in WebFlux which can serve as an example. However, in WebFlux there is only one path matching mechanism (parsed PathPatterns), and no other built-in path matching options. By contrast, Spring MVC historically supports String path matching via PathMatcher as well, which comes with various path parsing options on UrlPathHelper. That's in addition to (now deprecated) other built-in path matching options suffix pattern matching.

For applications that use only parsed PathPatterns, and don't have any other built-in path matching options enabled, we should be able to do the same as in WebFlux, but we'll need to expose an easy way for Spring Security to determine if that's the case or not.

In addition, we'll need to expose some support for Spring Security to handling CORS preflight requests with awareness of fine-grained CORS config at the handler level. In WebFlux, DispatcherHandler is a PreFlightHandler and exposed as a bean, which allows Spring Security to find it and use it. We'll need something comparable in Spring MVC.

[rstoyanchev]

@rwinch @jzheaux I've made a couple of changes.

First, HandlerMappingIntrospector has a boolean method called allHandlerMappingsUsePathPatternParser that checks if all handler mappings use PathPatternParser. That in turn means AntPathMatcher and UrlPathHelper which come with a range of path parsing options, are not in use.

When this method returns true, it should be possible fine for Spring Security to just use PathPatternParser for request matching, just like what is done for WebFlux.

In order to handle pre-flight requests, there is now a PreFlightRequestHandler for use in Spring MVC like the one for WebFlux. HandlerMappingIntrospector implements it, and that allows Spring Security to handle pre-flight requests directly without delegating to the rest of the filter chain, like what is done for WebFlux.

I think this is a good time to have a look at changes on the Spring Security side to make use of this.

[rstoyanchev]

I'm closing this as the API changes necessary for Spring Security to take advantage have been created. We'll created additional issues as needed.