Response to post #11 http://www.yiiframework.com/forum/index.php?/topic/8400-module-hrbac/page__view__findpost__p__46994
- What are computed roles and how to use them?
Consider the situation where a user is viewing a post that he authored. Here, the role ‘Author’ would be dependent on the target object. Or consider the situation where a group of writers is supervised by an ‘Editor’. The ‘Editor’ role would then depend on whether the target object or post was written by a writer from the users team. The Computed Roles is there to help with these kind of situations, where you might want to assign a role to the user based on information about the target object.
When you need this functionality, define a public function getComputedRoles() in your controller. This function would then return an array of roles (strings). The array can be empty.
-
I copied that code from the Yii core file. I don’t really know if there’s any performance benefit.
-
Hrbac extends the rbac feature of Yii core. PhpRules (called bizRule in the documentation) are a feature of the Yii core. It allows you attach php code to any auth item (roles and such) which would further check if an assigned role is enabled for that particular request. Using this, you could - to give a simple example - specify that a person is a moderator only from 9am to 11am.
Personally I don’t like the idea of executing php code from a database. Hrbac provides ‘Conditions’ that should help avoid PhpRules.
Additionally if we don’t use PhpRules, it improves the performance of checkAccess(). There are fewer database queries.
- You might be right, “LIKE ‘$route%’” would probably be faster. It would also make
if($routeCheck && strpos($itemName, $row['name']) === 0)
return true;
redundant.
- AuthPath table has distance field.
Yes, this is the generational distance in the hierarchy. An items distance from itself is 0, from it’s parent or child is 1, from it’s grandparent or grandchild is 2 and so on.
This entire table is for performance purposes and should not be edited manually.
- Column ‘path’ in table ‘AuthPath’
This again is for performance and deals with the hierarchy. It contains the items in the hierarchy between an ancestor and a descendant.
The code is basically to check whether a role has permission for a given operation within a single db query. Remember that a role might contain another role, which in turn may contain an operation group which in turn might contain the operation that we want to test for.
7.a ) Bizrule and data
The ‘data’ used by bizRule has to be in the database. However, Hrbac does not contain any user interface to specify this data as the data is considered to be binary. This is part of the Yii core. You will need addition code in your application to enter this data in the db. I can imagine that this might be useful where a user subscribes ( role : Subscribed User ) through a payment service and they provide data specifying how long the subscription is valid for.
7.b ) Conditions and runtime data
You can provide data for use with conditions by specifying the $paramsCond parameter when calling checkAccess(). When $paramsCond is not provided then the $_REQUEST global variable is used instead.
7.c ) Editing own profile
This is where ‘Computed Role’ comes in. A user would have the role of ‘Owner’ or ‘ProfileOwner’ but instead of this role being assigned in the DB it would be assigned only at runtime based on the target object ( the profile in this case). The ‘Owner’ role would have permission to edit a profile. See the first item in this post.
Note that you’d have to save any data queried from the DB in the controller so you don’t query for the same data when the action is finally called.
As to doing the check automatically, I don’t have any ideas in that regard.
7.d ) Yii::createApplication(‘HrbacWebApplication’, $config)->run();
This line just replaces the default line
Yii::createApplication(‘CWebApplication’, $config)->run();
and creates the subclass HrbacWebApplication instead of CWebApplication
7.e ) Negative rules.
For what you’ve described, you could use bizRules or Conditions.
For example, you could have a role ‘ForumModerator’. You could then create a role ‘ChineseForumModerator’ which could contain the role ‘ForumModerator’ but with the condition that forumid equals chinese. Or you could assign the role of ‘ForumModerator’ to a user with the condition that forumid equals chinese. That user would then be able to moderate only the Chinese forum.
As for blocking IP addresses, personally I’d have that be a separate system from the rbac.
