Introduced DispatcherType request matcher

[nmck257]

Created a DispatcherTypeRequestMatcher and corresponding methods
for configuring an HttpSecurity object. This enables filtering of
security rules based on the dispatcher type of the incoming servlet
request.

Additionally, removed duplicative code for parsing HttpMethod objects
from the AntPathRequestMatcher and RegexRequestMatcher.

Closes gh-9205

[nmck257]

FYI - checks are passing now.

(sorry for the noise -- struggling to get my local checkstyle/checkformat config to match up w/ the project)

[eleftherias]

Thanks @nmck257!
I have left some feedback inline.

[eleftherias]

Thanks @nmck257!
This is now merged into master.

Are you interested in submitting a similar PR for the server equivalent?
This would involve creating a DispatcherTypeServerWebExchangeMatcher that implements ServerWebExchangeMatcher.

[nmck257]

Are you interested in submitting a similar PR for the server equivalent?
This would involve creating a DispatcherTypeServerWebExchangeMatcher that implements ServerWebExchangeMatcher.

Sure @eleftherias -- I should have time to do so a little later this week.

[nmck257]

@eleftherias - want to make sure I understand the intent for the DispatcherTypeServerWebExchangeMatcher.

The ServerWebExchange and ServerHttpRequest interfaces don't expose a DispatcherType directly.

But, I do see that if a request is adapted through ServletHttpHandlerAdapter into a ServletServerHttpRequest, then that particular ServerHttpRequest implementation has an HttpServletRequest field which will preserve the DispatcherType from the servlet context. And that field is available through AbstractServerHttpRequest::getNativeRequest with some casting.

So... is that the scope? The new matcher should check whether the incoming request is an instanceof ServletServerHttpRequest, and if so, pull back the DispatcherType from the request's servlet background for the comparison? And non-match requests which aren't ServletServerHttpRequest?

[eleftherias]

Thanks for pointing that out @nmck257.

I was too quick to assume that there should be a server equivalent, when in fact this doesn't make sense for server based applications.
That means we don't need the additional PR.

Sorry about the confusion and thank you for setting us on the right track.

[nmck257]

Got it - no worries.

Thanks @eleftherias !

[simaotwx]

I was too quick to assume that there should be a server equivalent, when in fact this doesn't make sense for server based applications.

What do you mean by this? The PR says

This enables filtering of security rules based on the dispatcher type of the incoming servlet request.

"incoming servlet request" → server

Why is this not for server? I don't understand that.
Also, does this work in Kotlin using the DSL?

[simaotwx]

Also, does this work in Kotlin using the DSL?

Found it: https://docs.spring.io/spring-security/reference/servlet/authorization/authorize-http-requests.html#match-by-dispatcher-type