I’ve created a db-based role based access control and it’s working like a charm, except for one thing.
When the user doesn’t have the permission for a child item, the parent is checked, and if he does have that one, the user is authorized.
That’s perfect.
But if the child item is connected to a rule, after verifying if the rule returns false, a 403 exception is thrown without checking parentes permissions.
Why? The logs confirm the parent permission is never checked.
The rule is a kind of "gate" between the child and the parent.
The key point in the RBAC section of the guide is, arrows and their directions in the graphs. When a user wants to do some action, there must be at least one path which starts from the action and reaches to the user following those arrows.
When an auth item has a rule, it acts like a gate to the next item. If it returns false, then you can not proceed to the next item.
Ok, so if i’d want to let a standard user update his own user data, and let an administrator user update everybody’s data, i’d have to check inside the rule if the user has the UpdateEverybody permission?
We start from "updatePost" both for standard users and administrators. We use the same code for checking permission, no matter whether he/she is an admin or not:
if (\Yii::$app->user->can('updatePost', ['post' => $post])) {
// update post
}
If the user is an admin, then he/she can follow the path from ‘updatePost’ via ‘admin’ to him/her, because ‘admin’ is a parent of ‘updatePost’ and he/she has the role of ‘admin’. The parameter $post is not used in this case.
But when he/she is a standard user, having no ‘admin’ role, he/she has to take the path via ‘updateOwnPost’ and ‘author’. The parameter $post is not used in ‘updatePost’, but will be passed to ‘updateOwnPost’ and evaluated by the ‘AuthorRule’.
