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.