1
votes

i am messing around with the cakephp 2.0's access lists, so far i created a very simple example following the documentation.

I have set up a users table and the most important functions like index, add, login ecc. and is related to a groups table (every user belongs to a group).

I've also created a "houses" table wich contain different contents (houses).

Then i've set up auth in combination with the acl-component in crud mode, including the aco and aro tree.

So far so good, everything is working so far, i can allow or deny single actions for every user. But, i want further access control, that for instance a user can manage only a specific house. So i've set up an aco for every house, allowed only read-access to the houses to the user and allowed update access only for the desired house. But it won't work! No matter what i do.. i don't get access to the edit action. Here my trees:

Aco:
[1] Houses
  [5] House.1
  [6] House.2
[2] Users

Aro:
[1] superadmin
  [4] User.1
[1] admin
  [5] User.2
  [7] User.4
[3] customer
  [6] User.3

And finally the aros_acos table:

id  aro_id  aco_id  _create _read   _update _delete

4   1   1   1   1   1   1
5   1   2   1   1   1   1
6   2   1   1   1   1   1
7   3   1   0   1   0   0
8   7   1   -1  1   1   -1
9   7   5   1   1   1   1

Fact is, that, if i try to do a quick check with:

 var_dump($this->Acl->check(
array('model' => 'User', 
'foreign_key' => 4),
array('model' => 'House',
'foreign_key' => 1),
'update'));

It gives back true!

Strange... Am i doing something wrong? Is there any way to decently debug the acl component (with information wich acos and aros the component is checking, seeing ecc.)?

1
Any update on this question, I am also trying to achieve the row level control with CakePHP ACL ver 2.6.1.Aditya

1 Answers

1
votes

Based on your aro_aco table, it looks like this is correct behavior. User.4 belongs to the admins group which has update permission. set to true in row 8. You have a rule in row 8 specifically for User.4, but you have granted update permission specifically to that user in that row. It appears that the ACL rules are working exactly as you have them setup. To prevent User.4 from using the update permission, run this at the cake command line to update your rules for User.4:

cake acl deny User.4 House.1 update

It should then return false when you run a check:

cake acl check User.4 House.1 update

EDIT

I'm going to attempt to revise this based on comments left below. I think that you may still be setting up the rules incorrectly. I am going to use the command line examples (because it's either to both type and to do in practice) but you can just as easily write the PHP to do this. My examples below also focus on admin, but you could use for the superadmin and users groups too.

First, deny everything to admins since we want to grant permissions individually:

cake acl deny admin Houses all

Then, grant the read only permission to admin so they can all read Houses:

cake acl grant admin Houses read

Lastly, grant the update permission to the specific user that gets update privileges:

cake acl grant User.4 Houses.1 update

These permissions should allow User.4 to read and update the House record. Keep in mind that if you have already created deny or allow records for User.4 then this example may not work. You may want to truncate your aco_aro table and start over since it's small at this point.

If all acl checks work, but the behavior is still incorrect, then you may have an issue with how the ACL component is authorizing an action. You may have to tweak those settings in $beforeFilter or your $components array.