Thank you so much for the tutorial, I was looking for this during the last days.

I miss in the tutorial the register action for the users.

which are the passwords you have used for the users in the file?

@Alberto: I thought I put the passwords in the README.txt but every user’s password is ‘pass’. As for the register action. I never made one, as in the first part I directly added the users to the database via users/add. But there is no reason that users/add could not be adapted to make a users/register action.

Hi!
Great tutorial, very useful!
What I am missing here, is the ability to restrict users to edit only their own post and not everyone’s.

Hi Mark, great follow up post on ACL. However, is there a reason why you did not use Configure::listObjects(‘controller’) to get the list of controllers? In the end it doesn’t really matter since this is run-once code…

Mark,

Looks great, thanks for this. You sent me the proof and I thought I got it then but you’ve hammered it home now. The one thing holding me back from jumping in with ACL and sticking with my own isAuthorized schema is that I can’t piece together how to manage ACL so that each individual record in the DB can have view/edit/delete set individually based on per user or per group settings. Any ideas? Maybe a part 3 hint hint

Thanks so much.

Sincerely,
~Andrew Allen

@Andrew: Just add an additional layer to the ACO tree, so that you have something like:
controllers->Posts->{edit/view/delete}->individual_post_identifier.

@Joel I originally wrote this script for CakePHP 1.1 so that would explain the absence of Configure::listObjects(). I’ve updated the function on the page to reflect the addition of Configure::listObjects().

@Joel and/or mark story I’m confused about “Just add an additional layer to the ACO tree”

Wouldn’t you end up with a lot of extra records in your aco table? for example, if there are 6 actions in a posts controller, you would end up with 6 ACO records for every post…

You made it man…
there wasn’t such well explained ACL usage til now, and you know many people tried it already…

now, about Andrews question: Andrews : Acl got a per model support, so you could fill your aco's table just as Mark filled the aro's. And permission's table (acos_aros) got the CRUD corresponding fields. I'm not sure how to implement it on the a app, but it's a lot of thing to get your head on already. Mark : you could cover it! You did it so nice…

Mark – still enjoying this set of tutorials. Thanks again for putting them together. You said to “Take out the references to Auth->allowedActions in your users and groups controllers.” When I do this and then try to access a restricted controller/action with a user who doesn’t have the rights to do so an endless loop is created. (They are sent to the login action which they don’t have access to and thus the loop.) I believe the login and logout actions need to be permitted to all users to prevent this. Can you comment? Thanks again.

shouldn’t
cake acl create aco null controllers

be
cake acl create aco root controllers

at least the first doesn’t work for me.

Sandy: You are correct, I’ve updated the tutorial, thanks :)

grncdr: I would strongly advise against adding an aco for each action for each record. This will balloon your aco table, and make an utter mess. A better solution would be to make a separate tree for models, and set CRUD permissions for each record. I’m planning on covering this in the future.

Jason: I haven’t been able to reproduce that issue. But if you keep having issues e-mail me.

Hi ;

Great tutorial something really confused me . Whi I run the function buildAcl() it created many fields in the acos table . Thats great but since every controller has an index how can I know which index record belongs to which controller ?

Mark,

Great tutorial :) Thanks for taking the time to write it.

I don’t think its any fault of the tutorial, but does anyone else get infinite redirect loops? When logged in as Administrator or Manager and trying to visite /users/add I get infinite redirects.

Excuse me I meant to say User or Manager.

Figured it out. I had to allow the display action in PagesController.

Mark sorry for the mess of comments please condense/edit/delete as you please :(

@HeathNail – I was having the same problem. Thanks for noting your fix.

Sorry for all of the comments but I came up with another solution for my redirect problem. For reasons I have yet to figure out, Cake was trying to redirect to ‘/’ when a User or Manager tried to access a Admin level ACO. This caused the infinite loop. By going to the routes.php file and changing the ‘/’ location to Users::login I stopped the looping. I’m not totally sure why Cake tried to redirect to ‘/’ when the loginAction was set to ‘users/login’. It seems like a hack of a fix since others haven’t mentioned the need for such a tweak—but at least it’s working.

Jason: Don’t worry I think its good that there is an ongoing conversation about this. As for redirecting to ‘/’. It could be the result of an empty referer. If a user is not authorized, and accesses a page they do not have access to via direct input into the browser address bar there will not be a valid http referer. The way that Cake handles this is the referer becomes ‘/’ . This can also happen when the browser doesn’t send referer headers.

Yeah, I think that’s it. I was always entering a non-authorized ACO into the address bar to see what would happen. I tried adding a link to see what would happen when a referrer was present. I expected to be directed to the loginAction but I’m redirected to my current location. I believe this is the result of already being logged in so I’m sent back to the referring page. The behavior of the Auth component is slowing coming to light.