I had this weird bug in my webapp that while debugging I noticed that the “default roles” are not loaded right. I tracked it down to the usage of RbamModule::beforeControllerAction(). Its as if this function didn’t always run and thus the default roles defined in RbamModule were not array_merge()'d into the authManager->defaultRoles.
I think the issue is that its not always that this method (beforeControllerAction()) will be called. Its only when the actions from this module will be called, that this method will “wake up” and called before any action from this module is run. To complete the picture, there’s also CWebApplication::beforeControllerAction() which since its in the web application level (and as explained in the docs), will always run before the controller that is determined to run by Yii.
If I’m correct then this is possibly a bug since nowhere in the documentation I noticed that defaultRoles should be defined for either RBAM module or Yii’s stock CdbAuthManager.
Compare your PHP environment settings: make sure that mod_rewrite is enabled in both apaches, and in general compare the two environments. I recommend comparing phpinfo() output on both and have someone who is familiar with the environment (the LAMP stack - Linux, Apache, PHP, MySQL) assist you. I don’t know what option is it that controls case sensitivity but I guess that will be solved by the steps just recommended.
Also, make sure dot files, .htaccess namely, are transferred between servers as well.
I’ve stumbeled upon the bug described below. Intrestingly, when looking at “auth assignments”, the fitler shows both upper case and lower case results, but when examining “auth items”, only upper case rows are shown when clicking on the “go to letter” filter.
Anyone got some resolution to this, or even a pointer?
Is this extension still being maintained? I’m finding quite a few bugs and I wonder whether there is a place where it makes any sense to report them or if rbam has been abandoned and I should instead consider using some other rbac management extension.
The information page of the extension doesn’t provide any link.
Every time I open the "Auth Items" page, the httd process on the server consumes around 80% CPU for several seconds!!! (up to almost 20-30 seconds). This is ridiculous.
And I only have around 40 auth items counting roles and operations.
maybe try to profile it in some way. if it happens in large percentage of the tries, consider firing up a profiler on this, which is available in many modern IDEs (although its years now since I last tried a profiler. I think that xDebug can do profiling).
Looks like the problem is in having a lot of auth assignments.
The problem is getting worse and worse (in the AuthItems page, not the AuthAssignments page!!) as the number of users (and hence of assignments) gets growing, though the number of auth items doesn’t increase.
This may be because of the number of users that is displayed besides each auth item (number of users having that item assigned). Maybe it’s computed in a very inefficient way, or maybe it’s computed in the only way possible and that’s intrinsically inefficient - in which case it is a very bad idea to display that user count there (at least without caching it).
Now I can’t even get to see the list of auth items because the script reaches the execution time limit.
Well, I went into specified file: "RbamDbAuthManagerBehavior.php" on line 164 and just put $uid between simple quotes. Now it looks like this:
$condition = 'type='.CAuthItem::TYPE_ROLE." AND name NOT IN(SELECT itemName FROM {$owner->assignmentTable} WHERE userid='$uid')";
Additionally in order to make RBAM work with PostgreSQL, all tables must be double quoted, so I’s search for SELECT and I placed each table between double quote. Something like this:
$sql = "SELECT COUNT(child) FROM \"{$owner->itemChildTable}\" WHERE $condition";
because: "When NOT using table names with double quotes in Postgres it assumes the table name is all lowercase."
and table names are: AuthItem, AuthItemChild and AuthAssignment…
or you change the table names to lowercase
I am using yi-1.1.12.b600af and postgresql-64x-9.1 .
Well is working fine (except for the lower case and filtering issue noted in this thread above…) but now I noticed that if I rename an auth item the "auth_items" table gets updated but the relationships table does not get updated!
Could this severe bug have went unnoticed thus far or is it an overlooked “PEBCAK” that we all fall into occasionally?
<sarcasm>Of course it’s a PEBCAK. If you rename an authorization item it’s up to you to update all the auth assignments referencing it. No reason why RBAM should take care of that.</sarcasm>
Actually the correct behavior would be to warn you and give you the choice: “This item has assignment: do you want to update them?” but it doesn’t even check.
If you want it to always do the cascade update and you don’t care about being able to occasionally not do it, you may accomplish it at the database level by creating a foreign key in the auth_assignment table (item_name field) with a “ON UPDATE CASCADE” (you also need to make sure the item name is the primary key in the auth_item table or at least an index, i think) if the tables use an engine that supports it. Haven’t tested it, though.
Well, I totally disagree: is there any use case in which you rename an auth item and do NOT want the auth relationships table to get updated? Of course not.
That’s why its basic that the GUI for RBAC manipulation will handle such renames use case (atomically - transactionally).
The RBAM module has nothing to do with the strange design that creates this problem in the first place. If the auth items table had a numeric primary key with a foreign key to relationships table this would have been solved as the relationships would have contained only the numbers, not a copy of the name.
Anyhow, the idea of using some DB level constraint with a "ON DELETE CASCADE ON UPDATE CASCADE" sounds good, but it needs to be checked, as you pointed out.
I hope you didn’t miss the “sarchasm” tags in my post. I do agree with you that it’s absolutely basic that RBAM should check whether the updated item has related assignment and if it does, allow you to automatically update them. It’s a huge bug (or the lack of an absolutely basic feature, which is the same) that it doesn’t. It would be much better if it did, always, automatically and without asking. But the really correct behavior would be to warn and give you the choice (probably with the “yes” choice checked by default).
That you and me can’t think of a use case where one may need it, doesn’t mean that it doesn’t exist. Whenever there may be even the most remote possibility that one freaky guy in the world may need a behavior different from the default, the possibility to change it must be provided. But I agree with you that the behavior you describe should be the default one.
Actually, here’s a use case.
I have assigned 20 users the ClockwiseDancer role, and I have assigned other 30 users the CounterClockwiseDancer role. Oh shit! Clocks turn that way!! All my assignments are reversed! Well, know what? If I rename ClockwiseDancer to CounterClockwiseDancer and viceversa (of course in 3 steps using an intermediate dummy name), that’ll do the trick.
