RBAM - Role Based Access Control Manager
Management of RBAC Authorisation Data via a web interface

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.

When passing from my dev machine (windows) to the testServer(Linux) it gaves me this:

Error 404
Cannot resolve request "rbam"

When I change

rbamController.php

to

RbamController.php

Only the initial page works.

Can anyone help me?

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?

Schorsch0815, on 07 February 2011 - 04:01 PM, said:

Nice extension to manage the rbac within an application. After playing around a little bit with the demo. I figure out a small problem with lower case operations, tasks and roles when managing relationships:

E.g. if you define two operations 'operationOne' and 'OperationTwo' you will see the letter 'O' is enabled but when you click it just the upper case operation 'OperationTwo' will be shown. The lower case items will be recognized when enabling the alphabetic filters but will not be displayed.

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.

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.

When I go the the RBAM "Auth Assignments" page; and click on the icon for "Assign role(s) to this user", I get the following error:
Undefined function: 7 ERROR: operator does not exist: character varying = integer

The SQL statement executed was: SELECT* FROM AuthItem WHERE type=2 AND name NOT IN(SELECT itemName FROM AuthAssignment WHERE userid=9)

The userid column of AuthAssignment is of type VARCHAR(64) but it is being compared to an integer. I'm confused about how this query can work, as when I look in the AuthAssignment table, column userid contains usernames such as Administrator, which cannot be compared to an integer.

Everything else works as far as I can tell, so if the above can be solved, I should be able to use this very helpful extension.

I had the same error.

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:

Why My Rbam didn't work out for generation Auth, but in some machine I tried it worked successfully
This is my not working rbamrbam_not_worked.png(86.7K)Number of downloads: 15
This on my other machine woked finerbam_ok.png(38.61K)Number of downloads: 15

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?

Could this have went unnoticed thus far? 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.

<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.

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).

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.
Unlikely, I agree. Impossible? no.