Posted 27 May 2009 - 02:37 PM
When using the filter "accessControl" in a controller we can specify accessRules with certain context parameters. The documentation reads: "roles: specifies which role that this rule matches." I think this should say "roles: specifies which authorization items (operations, tasks, roles) this rule matches", at least this is what the code seems to do. Maybe this context parameter should be renamed to "authItems" to prevent this confusion.
Or did I understand something wrong?
Posted 27 May 2009 - 11:40 PM
A user has the role "admin". The role "admin" has the task "manageBlog". The task "manageBlog" has the operation "deletePost".
In the PostController I would then specify an accessRule for the delete action:
'role' => 'deletePost'.
When really using RBAC then there should be no situation where one would specify 'role' => 'admin'.
I think this should be mentioned in the documentation, currently it reads like you would always have to manually check by doing Yii::app()->user->checkAccess('deletePost').
Posted 29 June 2009 - 11:14 AM
I think main confusing factors are:
1) Code sample from "Defining Authorization Hierarchy" should be finished with $auth->save() and text description should say this authorization rules setup should be performed only once (to auth.php or to database).
2) For database storage should be used framework\web\auth\schema.sql (there is note about it in the class reference, but no in the Guide).
3) Should be a code sample of using RBAC operations in accessRules()
public function accessRules()
A reader should clearly understand that in accessRules() can be used operations/tasks names and not only role names.
And I still can not understand what is the difference between tasks and operations?
I now used RBAC for system we are developing now and it is really easy to use and flexible, but I think documentation now prevents Yii users from using RBAC.
Sorry for poor English. And great thanks to Yii developers for great framework.
Posted 29 June 2009 - 02:18 PM
Regarding the classification of role -> task -> operation, they are essentially the same thing, as you can see in the code they are of class CAuthItem. We name them differently mainly from user point of view.
- Operations are only used by developers and they represent the finest level of permission.
- Tasks are built on top of operations by developers. They represent the basic building units to be used by RBAC administrators.
- Roles are built on top of tasks by administrators and may be assigned to users or user groups.
The above is a recommendation, not requirement. In general, administrators can only see tasks and roles, while developers only care about operations and tasks.
Posted 04 April 2010 - 04:55 PM
So, then, is it correct to assert that auth item type does in no way influence any logic in the framework code, that is, all these types are treated absolutely equally everywhere an auth item can be used?
Also, it is not clear from either the Guide or the Reference, how "additional data associated with the item" can be used after supplying it to createAuthItem().
I would also suggest to introduce some parameter that would represent a context of assigning a role to a user, e.g. an object that this role is assigned to this user for. Like this: user="John Doe", role="Moderator", object="this forum branch". As it is now (as far as I understood the docs), if I want to implement such an assignment, I have to write my own AuthManager. Or I can make all roles "default" and put some user-object checking into bizRules.