This is already the case in WebFlux which can serve as an example. However, in WebFlux there is only one path matching mechanism (parsed PathPattern
s), 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 PathPattern
s, 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.
Comment From: 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.
Comment From: 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.