[Boaz]

Question that might indicate a bug:

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.

Comments?
Thanks,
Boaz.

[Thureos]

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?

[Boaz]

Thureos, on 19 June 2012 - 11:15 AM, said:

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.

[Thureos]

Thureos, on 19 June 2012 - 11:15 AM, said:

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?

I had to change every controller and views folders to this format

controller folders...
from

authAssignments

to

Authassignments

and
views folders...
from

authAsignments 

to

authassignments

[huanito]

Thureos, on 19 June 2012 - 11:15 AM, said:

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?

most likely you are using apache web server. Apache on linux is case sensitive for URLs. Search for 'apache case sensitive url' for solutions.

[Boaz]

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.

[matteosistisette]

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.
Since the manual is hosted at http://rbam.pbm-webd...rbam_manual.pdf I tried http://rbam.pbm-webdev.co.uk which only shows embarrassing php errors, and http://pbm-webdev.co.uk which shows a default placeholder page from the hosting provider.

[matteosistisette]

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.

[Boaz]

matteosistisette, on 14 August 2012 - 03:37 PM, said:

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.

strange. I have almost 130 auth items and I suffer from no such thing. Can't think of a reason for your problem...

[matteosistisette]

Actually there are times it does not happen........

[Boaz]

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

[matteosistisette]

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.

[matteosistisette]

I can confirm: after removing the column that shows the user count, the authItems index works fine.

[Boaz]

matteosistisette, on 12 September 2012 - 03:54 PM, said:

I can confirm: after removing the column that shows the user count, the authItems index works fine.

thanks for the feedback. might be useful for others (like me, when the site hits the air).
maybe post a little diff output (other otherwise instructions) for your change?
TIA!

[firefly]

Bill Stoddard, on 19 May 2011 - 07:02 AM, said:

I installed RBAM using a PostgreSQL 8.4.4 database.

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:

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

[xicond]

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

kindly help me, ask me if any

Thx

[Boaz]

Could this have went unnoticed thus far?

My RBAM setup included non-standard tables names. They are configured in authManager configuration:

'authManager' => array(
	'itemTable' => 'auth_items',
	'itemChildTable' => 'auth_relationships',
	'assignmentTable' => 'auth_assignments',
)

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?

[matteosistisette]

Boaz, on 17 October 2012 - 03:43 AM, said:

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.

[Boaz]

matteosistisette, on 17 October 2012 - 06:20 AM, said:

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

[matteosistisette]

Boaz, on 17 October 2012 - 06:26 AM, said:

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.