With respect of storing which user has which roles, I find the database storage to be more logical. It may envolve a lot of data, one or more row per user, so database seems better. This data changes all the time with the life of the site.
However with respect of storing hierarchy, authorization items, I find it makes more sense to store them in a file. The reason being that I can easily ship my PHP project with built-in hierarchy without having to export SQL data. Defining the auth items is part of the creation of the site, therefore I don’t think it should live in the database.
Does it make sense? Is there a way to cleanly combine both?
On a smilar note, the example of a "BizRule" is very simple in the documentation. What if I had more complex business rules? Can I have a function/method somewhere that the business rule will call?
Third question: Let’s say I want to have a “moderator” role. However I have moderators for “categories”. So Moderator A can moderatore category A while moderator B can moderate category B. Can the basic hierarchy work with this?
What a coincidence - it’s just yesterday that i wrote exactly the class you just describe: It extends from CPhpAuthManager but takes some parts from CDbAuthManager to get the assignments from DB. So yes: I think it does make sense.
I did this for a client, but maybe he agrees, that i release this class as extension, if you’re interested.
It will not be compatible. yii-rights enforces you to use a couple of base classes and configure the auth manager component which comes with the extension. One of the reasons why i don’t really like it very much.
I’ll publish it as an extension over the next days.
Totally up to you: Use a global function, collect your functions as static methods in a custom class, …
You could use business rules + another table for this. In that table you connect moderators to categories e.g. with columns moderator_id and category_id. Then you create a role Moderator with a business rule. The business rule checks, if a record exists for a given moderator and category. In your call to checkAccess() you supply the current moderator and category ids as parameters to the business rule.
my reply to the Nathan’s “moderator scenario” is the same as yours : I have added a new table to connect users to categories (let’s call it user_mod_cat). With a bizRule associated with the Moderator Role, it works fine, however, I have a doubt about it …
[size="3"][color="#4169E1"]why use a role ?[/color][/size]
… I mean, isn’t a record in the user_mod_cat table enough to state that a user can moderate the category he is linked to ? why assign a role to the user then ? what are the benefits ?
On the project I’m working on, I have plenty of equivalent scenario, where a role is granted to a user on a particular instance(es) of models : user can manage Group(id), user can update Posts(id) etc… should I create a link table in each case ?
If for a given user and for a given category I want to revoke moderator role I have to:
[list=1]delete the corresponding record in the user_mod_cat tablecheck that at least one record exist for this user in the user_mod_cat table and if it’s not the case, actually revoke the role for this user[/list]
I guess that’s correct isn’t it ? But then again, why no forget about roles and just handle the user_mod_cat table ?
Maybe the solution is to create one role per category and then assign it to a user ? Assigning moderate_category_A
Or maybe it would be more logical to create a moderate_category_A task, and then add this task to the moderator Role ?
Well as you can see, I’m far for mastering RBAC principles and hopefully you’ll be able to show me the good way to use it…
I understand what you mean, and you’re right, I would need some nice GUI stuff to manage assignements … but it can be done.
On the contrary what seems very difficult to do is to retrieve a list of all users who are moderators for a specific group… don’t you think ?
… I definitly need to study the subject because until now (and for this particular use case), RBAC seems to be a problem … not a solution. The ‘updateOwnPost’ bizrule in the doc is not enough to understand how to handle this case.
There may be situations where another link table is not feasable and where you can map everything into RBAC rules instead. But i prefer to not have cluttered my RBAC with 100s or 1000s of tasks/roles.
And there’s one advantage of using roles: You can just revoke the role from the user to disable access for him, without loosing all the connections (in case you want to re-enable it later). BTW this is enough to disable user access: I don’t think you need the 2 steps you described above. If either one of the conditions is met (no role assigned, or no entries in link table) then no access is granted.