When someone passes null
for the method
to WebInvocationPrivilegeEvaluator
, they are saying that the HTTP method doesn't matter to them for matching purposes. However, it's non-trivial to make an authorization decision in any circumstance where the relevant request matcher does require a method.
Imagine the following arrangement:
.requestMatchers(HttpMethod.GET, "/path").hasAuthority("USER")
.requestMatchers(HttpMethod.POST, "/path").permitAll()
When WebInvocationPrivilegeEvaluator#isAllowed("/path", authentication)
is called, which matcher's authorization rules should it use?
This happens in the more generic case as well:
.requestMatchers(HttpMethod.GET, "/path").hasAuthority("USER")
.anyRequest().denyAll()
Or, in other words: "if GET /path, then require USER authority; if POST | PUT | DELETE /path, then deny". Here, also, there's no way to know which the user intends, unless they also specify a method.
As such, I believe it's reasonable to require passing a method if you want method-specific request matchers to be considered, which is what the method currently does.
We should update the JavaDoc to be clearer about this, something like:
* Note that this will only match authorization rules that don't require a certain {@code HttpMethod}
Both isAllowed
methods should contain this clarification.