Comments on: Access Control Lists (ACLs) Part 3 http://www.hirdweb.com/2008/08/27/access-control-lists-acls-part-3/ Another Blog clogging up the already crowded internet Sat, 28 Aug 2010 13:44:42 +0000 hourly 1 http://wordpress.org/?v=3.0 By: stephen http://www.hirdweb.com/2008/08/27/access-control-lists-acls-part-3/comment-page-1/#comment-17 stephen Sat, 18 Oct 2008 12:27:40 +0000 http://www.hirdweb.com/?p=72#comment-17 Paul, I would be happy to help and get the solution put up here for everyone. Remember that Auth and ACL do different things. Using them together can provide a great security level. With the 'User'ACO, make sure that the user is not part of another group. Make sure that you are checking the user ACO and not the group ACO. So what you will need to do, is check the userID who is trying to edit, the userID of the object being edited, and then make sure that they have permission. My order of check: 1. grab the user account to be edited 2. Do an ACL check in an IF statement against the logged in User's ID to the account to be edited. 3. If they are not allowed an 'update' action, then redirect them to a page with a message 4. If they do have permission, then go forward with the logic. Also, make sure that the user account has an entry in the tables. The ARO table should include your 3 groups, and then have three entries for users with the parent_id being the corresponding group they belong to. The ACO should contain at least 1 parent group of objects which will be enacted upon. So in your example Users. And each user ought to have an entry in this table as well. The AROCS_ACOS table should have the entries for the users with the permissions to each ACO group (and user if need be). If this does not make sense, let's keep going and maybe you could post where the issue is going wrong and we can resolve this. Or you can email me as well. http://www.hirdweb.com/contact/ Paul,

I would be happy to help and get the solution put up here for everyone. Remember that Auth and ACL do different things. Using them together can provide a great security level. With the ‘User’ACO, make sure that the user is not part of another group.

Make sure that you are checking the user ACO and not the group ACO. So what you will need to do, is check the userID who is trying to edit, the userID of the object being edited, and then make sure that they have permission.

My order of check:
1. grab the user account to be edited
2. Do an ACL check in an IF statement against the logged in User’s ID to the account to be edited.
3. If they are not allowed an ‘update’ action, then redirect them to a page with a message
4. If they do have permission, then go forward with the logic.

Also, make sure that the user account has an entry in the tables. The ARO table should include your 3 groups, and then have three entries for users with the parent_id being the corresponding group they belong to. The ACO should contain at least 1 parent group of objects which will be enacted upon. So in your example Users. And each user ought to have an entry in this table as well. The AROCS_ACOS table should have the entries for the users with the permissions to each ACO group (and user if need be).

If this does not make sense, let’s keep going and maybe you could post where the issue is going wrong and we can resolve this. Or you can email me as well.
http://www.hirdweb.com/contact/

]]> By: Paul Gardner http://www.hirdweb.com/2008/08/27/access-control-lists-acls-part-3/comment-page-1/#comment-16 Paul Gardner Sat, 18 Oct 2008 12:14:53 +0000 http://www.hirdweb.com/?p=72#comment-16 Stephen, I am having great problems trying to implement Auth and Acl with CakePHP and hoped this article may sort me out, but whilst I now better understand the creation of AROs and ACOs I still don't know how to implement this in such a way that the system inhibits users from accessing certain sections of the site. I have created 3 groups (Master Admins, Admins, Users) and 3 users one linked to each group. I am assuming that if I deny the 'Users' group update rights for the 'User' ACO and a member of that group tries to update a user the system should stop them but it doesn't. Any chance we can try and get a conversation going which leads to me successfully getting Auth and Acl working in CakePHP and we can also pad out this article with the results as I am sure it would get you a lot of traffic and kudos (there are a lot of people struggling with this issue). Stephen,

I am having great problems trying to implement Auth and Acl with CakePHP and hoped this article may sort me out, but whilst I now better understand the creation of AROs and ACOs I still don’t know how to implement this in such a way that the system inhibits users from accessing certain sections of the site.

I have created 3 groups (Master Admins, Admins, Users) and 3 users one linked to each group. I am assuming that if I deny the ‘Users’ group update rights for the ‘User’ ACO and a member of that group tries to update a user the system should stop them but it doesn’t.

Any chance we can try and get a conversation going which leads to me successfully getting Auth and Acl working in CakePHP and we can also pad out this article with the results as I am sure it would get you a lot of traffic and kudos (there are a lot of people struggling with this issue).

]]>