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
You can see that user bob has 2 principals (user:bob and Authenticated) mentioned with the required permission: create in the ACL. But the actions collide. One principal allows access. The other denies it.
So, what is the final result when Bob tries to add an item? With the ACL above, he is denied access. But if you just change the order of tuples in the list to be the following:
This happens as the ACL is checked in order for matching permission and principal. In many scenarios, this doesn't matter. But if you need to use the library for a use case with principals with overlapping permissions, order matters. An example is having some users with a role allowed to do something but excluding a specific user holding that role from access. In this case, you need to always add the most specific principals at the beginning of the ACL.
In the
add_items
endpoint, the ACL to be checked is:You can see that user bob has 2 principals (
user:bob
andAuthenticated
) mentioned with the required permission:create
in the ACL. But the actions collide. One principal allows access. The other denies it.So, what is the final result when Bob tries to add an item? With the ACL above, he is denied access. But if you just change the order of tuples in the list to be the following:
He will be granted access!
The text was updated successfully, but these errors were encountered: