Chapter 8 : RBAC misunderstandings

Hi,

I’m a litle bit disapointed about the chapter 8. Here are the reasons:

  • Why adding this kind of bizrule in the AuthAssignment table: "return isset($params["project"]) && $params["project"]->isUserInRole("owner");" as the "owner" information is hold on the ItemName column and the rest remain constant, this information can easily be genarated bu the logic of the application.

  • What’s the purpose of the “AuthAssignment” table since all of these informations can be easily retrived in the “tbl_project_user_role” table. Just imagine we remove that first table, all the RBAC stuffs can be done with the “tbl_project_user_role” and the other tables.

  • Since RBAC roles are very limited in the TrackStar application, isn’t it a leak off performances to keep them inside a database table ? Keep them in a php array inside a file isn’t faster ?

The chapter 8 comes to me as a difficult one. All help or precision will be very appreciate.

I just finish the chap 8 and agree with you…

But, about the use of database I think that the author wants to demonstrate the RBAC capabilities… so, the use of database was a great choice.

The RBAC is one of the most important features [to me] from Yii… and it’s very hard to find out good samples using it.

I really expected a little more from this chapter.

  1. This biz rule allows us to add an extra dimension to using RBAC to check authorization access. We need to assign users to roles, and that is handled by the Yii RBAC implementation (AuthAssignment table in this case), but the thing is, the role is only applicable within the context of a specific project. The user can be an "owner" of Project A, just a "member" of Project B, and yet again only a "reader" of Project C. The AuthAssignment table just makes the association between the role and the user, i.e. it will just say User 1 is an "owner". The business rule makes the extra check to ensure that role does, indeed, apply to the context of the project they are currently within. This allows us to ask: "Okay, great, User 1 is an owner, BUT is user 1 really an owner of Project A?"

  2. You still need AuthAssignment to play by the rules of the underlying Yii RBAC implementation and get the advantage of the its hierarchical nature. We don’t just checkAcccess() at the role level, we do this at the task and operation levels as well.

  3. Housing this information in the DB will make it easier to wrap a nice GUI management around the rules, but Yii provides for a multiple implementations, so the choice is certainly yours to make, based on whatever specifications and requirements you are facing in your specific application.

Hope this helps, let me know if you have more questions.

Question, does this implementation assign every user each role(OWNER, MEMBER, READER) by default in the authassignment table?

for example,

lets say user 1 had a the OWNER role for project 1 and project 2, but then lets say we remove the OWNER role for user 1 for project 1 and 2, do we also have to remove row in authassignment for the OWNER role to user 1, and then lets say later on we want to make user 1 an OWNER for project 3, do we have to add a row in authassignment for the owner role for that user?

So basically if a user does not have a row in tbl_project_user_role for the OWNER role does it mean it also doesn’t have a row in authassignment for the OWNER role, and if a user has a row in tbl_project_user_role for the OWNER does that mean we create a row in authassignment for the OWNER role for that user???

iknow its confusing, i hope you can understand what i’m trying to ask :)

When I read through the book and came to the chapter about RBAC, I thought this was a nice feature. BUT… when I saw that they stored PHP code in the database I began to worry… do the framework rely on eval()?. I took a closer look into the Yii core and found it - they DID use eval().

eval() is one of the functions I disable on a new PHP installation. Having eval() enabled is like asking for problems, IMHO.

And if you have to use eval() - check your code very carefully.

I’m really having trouble with this database setup, too.

I would also like to quote the first answer in the "Identified issues"-thread:

Every time I assign a user to one of the three roles (member, reader, owner) in any of my infinite number of possible project, a row is added to AuthAssign:

itemname = role, userid = i, bizrule = …

So, let’s say I have my Test_user_two, id = 2.

I want him to be a member of both Project 1 and Project 2.

I add him to Project 1: the assignment is made in tbl_project_user_assignment and tbl_project_user_role, but also in AuthAssign.

I add him to Project 2: I get an error message, because the exact same row was already inserted into AuthAssign.

This seems like kind of a big issue to me. Am I getting anything wrong?

edit: I found a solution here in the forum, simply checking, before adding the row to AuthAssign, if this row is already in there. Unfortunately, the forum always tells me my post would look like spam if I try to link these posts or insert code.

Hi - my first post. I’ve managed to overcome all the typos etc up to this point (and that’s not necessarily a bad thing as even though its made my progress through the book slower, I think I’ve gained a better understanding by having to fix the errors). However …

I’m now having the same issue that christoph describes above - whenever I add the same user/role to two or more projects I get …

… originating from the last line of my ProjectUserForm.verify() method :

Whilst I can see that checking for an existing entry prior to calling authManager->assign() would get round this, it seems to go against what we are being "sold" as the way to manage permissioning with with RBAC. Is this really the correct approach (and if so am I right in thinking that a simple call to authManager->isAssigned() is the best way to check this)?

Many thanks.

Mark

I am new to Yii and this is my first post. I am in chapter 7 of the book and I managed to solve the problem of duplication an authassinment able.I hope it is a good solution for this error:

CDbCommand failed to execute the SQL statement: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate … by using isAssigned methos of authManager in assign method in ProjectUserForm.php model like this:

public function assign()

{


	if($this->_user instanceof User)


	{


		


		//assign the user, in the specified role, to the project


		$this->project->assignUser($this->_user->id, $this->role);  


		//add the association, along with the RBAC biz rule, to our RBAC hierarchy


                $auth = Yii::app()->authManager; 


		$bizRule='return isset($params["project"]) && $params["project"]->allowCurrentUser("'.$this->role.'");';                       


                    if(!$auth->isAssigned($this->role,$this->_user->id))


                        $auth->assign($this->role,$this->_user->id, $bizRule);


                    return true;


                   


		


            }


	else


	{


		$this->addError('username','Error when attempting to assign this user to the project.'); 


		return false;


	}


	


}

so in the if statement {if(!$auth->isAssigned($this->role,$this->_user->id))} , if the user has owner role assigned t them prior this,it won’t be duplicated and project will be assigned to user as owner and they are also available to add different users by different roles to that specific project.