You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
When someone passes
null
for themethod
toWebInvocationPrivilegeEvaluator
, 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:
When
WebInvocationPrivilegeEvaluator#isAllowed("/path", authentication)
is called, which matcher's authorization rules should it use?This happens in the more generic case as well:
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:
Both
isAllowed
methods should contain this clarification.The text was updated successfully, but these errors were encountered: