$info = $this->Member->read(null, $id);

// Check for permissions to edit this account
if ( !$this->Acl->check(array('model' => 'Member', 'foreign_key' => $this->Auth->user('member_id')), $info['Member']['username'], 'update') ) {
	$this->Session->setFlash(__('You are not allowed to edit this user. -- ' . $this->Auth->user('member_id'), true));
	$this->redirect(array('action'=>'index'));
}

While this works and is not that bad of an idea at all, there is a way to centralize this check and put it in the main app_controller.php file.

Depending on the scope of the project, or the business needs of the application, this check can be done and centralized so that there is not the need to put the ACL check in its form above in every action in every controller that needs to have this done. So for the Member controller, you may need to copy/paste the code above to check the ACL for permissions to view, edit, delete, add, etc. That is just one controller, what if there were others as well, like Post, Event, Pictures, etc. That is going to be a lot of code to write to check the ACL.

Now even though the Cookbook on checking ACLs shows a simple one line approach:

$this->Acl->check(array('model' => 'User', 'foreign_key' => 2356), 'Weapons');

it is not just a simple one line approach. There are other things to consider, like what do you want to do if it fails. Is there a specific error message, does it need to redirect to a certain page, and what about if the person needs to be logged in and not need any special ACL permissions.This can get to be a few lines in length, and have a few more things that need to be done. This would be per function/action in the controller.

What I have done, is put the check in the app_controller. This way I need to check it with one line of code, instead of a few. I know, this may seem trivial, but this is something that could get really drawn out in heavier applications.

In the app_controller.php file, I created two functions:
_enforceAccess()
_checkAccess()

First I will explain the _enforceAccess() function. Since I use the model method of ACL, the function is looking for the following:
model
user’s ID
Object being acted on
Action for the object
Redirect Page

I also do a check for logged in status as well, to make sure that if an action is needed after login, like viewing, then I can check that here as well, instead of per function in the controller. I set all of the parameters to null, in case there is no needed permission check and I need to check logged in status.

So the way this function looks after everything is added:

function _enforceAccess($model = null, $id = null,$object = null, $action = null, $redirect = array("/")) {
	if (!$this->loggedin) {
		$this->Session->setFlash('You do not have permissions to carry out the requested action.');
    	$this->redirect('/members/login');
    	exit();
    }
	if ($this->_checkAccess($model,$id, $object, $action)) {
		return true;
	}
	$this->Session->setFlash('You do not have permissions to carry out the requested action.');
	$this->redirect($redirect);
	exit();
}

This function first checks for logged in status, if the person is logged in, then I go to the next step, if not, then I would redirect to the login page to get the user to log in to perform this action. As a side note to this: If you are using the Auth component, after the person logs in, the Auth component will redirect back to the prior page where this check was made.

After checking logged in status, it makes a call to the _checkAccess() function and passes the parameters needed to check the ACL. If everything works out ok, and the person has the permission to do the requested action on the object, then the code sends it back to the controller to do any other scripts. The person is authorized, and so it lets them through.

If the person does not have the permission, then they are redirected to the page that is set as they redirect. If no page is given, then the default is just the top level page, or home page of the application. If you specify a redirect page. Either way, the error message is printed out for the end user.

In the _checkAccess() function, it requires the parameters to check the ACL:
$model
$id
$object
$action
This function does the straightforward work.

function _checkAccess($model = null,$id = null, $object = null, $action = null) {
	// safety check just in case
	if ( !$this->loggedin ) {
		return false;
    }
    // Just checking for logged in status in this case
	if ( is_null($object) && is_null($action) ) {
		return true;
	}
	// Check access to a specific record
	if ( !is_null($object) && !is_null($action) ) {
		if ( $this->Acl->check(array('model' => $model, 'foreign_key' => $id), $object, $action) ) {
			return true;
		}
	}
	// Everything failed, so return false
	return false;
}

The first thing the function checks is a safety check. Just to make sure, we check to see if they are logged in. If they are not, return false. This is not really a necessary step, but for this application, one of the requirements was paranoid-like logged in checking. The next feature is to make sure logged in users are authorized. If there is no real check for permissions, and they just want to make sure the person is logged in, then this is one method I use to check this. Your application may be different, and that is ok. The final feature is to check a real object and action. We just put the ACL check here, and return true if it is allowed. If all of the IF statements do not get run, then it returns false. So when if you use this method, make sure that the needed checks are done, and the parameters that are passed have a real value and are not just NULL.

So this accounts for the checks I do now. I take out the calls in the controllers and replace them with this call. To see this in action, lets look at a few examples.

A member is logged in and would like to edit their friend’s profile:

function edit($id = null) {
    $info = $this->Member->read(null, $id);
    $this->_enforceAccess("Member", $this->Auth->user('member_id'),  $info['Member']['username'], 'update', array('controller' => "members"))
    // The rest of the action code goes here
}

This will do all the checks for you, and redirect to the members index page if the person does not have permission to edit other user’s account information.

Another example: a person who is logged in wants to view all posts. Posts are visible to only logged in accounts.

function view() {
    $this->_enforceAccess();
    // The rest of the action code goes here
}

Since this is open to everyone who is logged in, we do not need to send any parameters over, we just need to make sure they are logged in. Since the _enforceAccess() function already checks for this, we do not need to do any further checks in this function.

Another example: an admin wants to delete an account, and this account is the admin account, (yes this has happened before where an admin was “three sheets to the wind” and trying to perform an emergency delete of an employee who was terminated, and tried to delete their own account):

function delete($id = null) {
    $info = $this->Member->read(null, $id);
    $this->_enforceAccess("Member", $this->Auth->user('member_id'),  $info['Member']['username'], 'delete', array('controller' => "members"))
    // The rest of the action code goes here
}

Last example: A member is logged in and trying to view all events for the group they do not belong to:

function viewEvents($group_id = null) {
    $info = $this->Events->read(null, $group_id);
    $this->_enforceAccess("Event", $this->Auth->user('member_id'),  $info['Events']['group_id'], 'view', array('controller' => "events", 'action' => "comingup"))
    // The rest of the action code goes here
}

In this check, the code pulls in the groups events based on the foreign key of group_id in the Events table. We are enforcing the the access to view these events, based on the person’s ID. If the person’s ID does not have permission to view the events for that group, it will redirect the user to the page events/comingup. Which does it’s own little thing. Each example here will spit out the error message in the _enforceAccess() function.

Now, even though these two functions added some more lines of code, it has reduced what is needed to be done in each controller. Instead of doing a check in each function in each controller, with its accompanying lines of code, you have just one check to do, usually in one line of code.

What works so well for me in this, is that the _enforceAccess() method can be extended. If you want a generic error message, and then do special errors on certain cases, add a new parameter for the error message, and a check to see if it is filled out. If it is use the special error message, if not, then use the default. If you need additional permission checks, this method also provides a central point to do those.

Remember that in any application, it is all what is required by the business/client/needs. This may work in some instances, and not in others.

First, the ACL happens after authentication. So whether or not you are using the Auth component, you will still need to authenticate the user some how, some way. Then once the user is authenticated and logged in, that user will have permissions to do different thing. Let’s say one of those things is to edit accounts. If it is a regular user, he should be able to edit his own and no one else. If the user was a “site admin” he should be able to edit his own and any account that is not a “super-admin”. If he is a super admin then he should edit everyone’s account. However, the first part of this is setting up the initial ACL permissions.

This step happens right on the account creation action. After the user has been created, and we grab the last inserted ID, we can update the ACL tables.

$usr = $this->User->getLastInsertID();

// Set up the ARO data for this user, assign as a member only at this point.
$aro = new Aro();
// Create the info for this new user
$user = array(
	'alias' => $this->data['User']['username'],
	'parent_id' => 4, // member ARO
	'model' => 'User',
	'foreign_key' => $usr
);
// Create the new ARO for the user
$aro->create();
$aro->save($user);
/**********************************************************************/
// Users are a little crazy because they are also ACOs
$aco = new Aco();
$aco_usr = array(
	'alias' => $this->data['User']['username'],
	'parent_id' => 2, // User ACO id
	'model' => 'User',
	'foreign_key' => $usr
);
// Create the new ACO for the user
$aco->create();
$aco->save($aco_usr);

// A User may update itself but not delete itself.
$this->Acl->allow( array('model' => 'User', 'foreign_key' => $usr), $this->data['User']['username'], 'update' );
$this->Acl->deny( array('model' => 'User', 'foreign_key' => $usr), 'Users', 'delete' );

$this->Session->setFlash(__('The User has been saved', true));
$this->redirect(array('action'=>'index'));

This will provide for the base permissions for the user.

Remember at this point, we are looking at ACLs from a user model only. If we wanted to extend this to groups, posts, calendars, etc we would add this in here as well. Say we also had a “posts” feature in our application, and we wanted to let the user create their own posts, edit their own posts, but no one elses:

$usr = $this->Auth->user('user_id');
$aco_posts = array(
	'alias' => $this->data['Post']['post_id'],
	'parent_id' => 4, // Posts ACO id
	'model' => 'Post',
	'foreign_key' => $usr
);
// Create the new ACO for the user to post
$aco->create();
$aco->save($aco_posts);

// A User may add, edit or delete their own posts, but not other user's posts
$this->Acl->allow( array('model' => 'Post', 'foreign_key' => $usr), $this->data['Post']['post_id'], 'update' );
$this->Acl->allow( array('model' => 'Post', 'foreign_key' => $usr), $this->data['Post']['post_id'], 'delete' );

So for anything that you want to limit the user access to, this is your chance. But remember the old saying “Keep it simple stupid”. Only do something if it makes sense and the project calls for it. I usually only do a User ACL in the users controller.

Now when you a user wants to go to an edit action after they are logged in, we need to check to make sure they can do this action:

$info = $this->User->read(null, $id);

// Check for permissions to edit this account
if ( !$this->Acl->check(array('model' => 'User', 'foreign_key' => $this->Auth->user('user_id')), $info['User']['username'], 'update') ) {
	$this->Session->setFlash(__('You are not allowed to edit this user. -- ' . $this->Auth->user('user_id'), true));
	$this->redirect(array('action'=>'index'));
}

The above code, broken out:

• $info gets all of the data about the id to be edited. It grabs the data from the table and stores it in the $info array
• Does a check to verify that they have permission, always checking for a NOT to be on the safe side
• The Acl->check is looking at the User model, since that is the object that is going to be edited (ACO)
• The Auth->user(‘user_id’) is the object requesting permission to do an edit (ARO)
• $info['User']['username'] is the exact ACO that will be updated
• ‘update’ is the action that will be taken on the exact ACO

If the test does not pass, and the currently logged in user does not have permission to update the user_id, then they will be redirected to a the index page for the controller.

Let’s also take the example above with the Posts, and lets say that a user is wanting to edit a post. At the very top of the function, we would put in a very similar check:

$info = $this->Post->read(null, $id);

// Check for permissions to edit this account
if ( !$this->Acl->check(array('model' => 'Post', 'foreign_key' => $this->Auth->user('user_id')), $info['Post']['post_id'], 'update') ) {
	$this->Session->setFlash(__('You are not allowed to edit this post. -- ' . $this->Auth->user('user_id'), true));
	$this->redirect(array('action'=>'index'));
}

In this example, we just replace User with Post and the info array elements. The same type of check could be done for delete, create and read actions in the controller. As you can see, this check could be done in a function in the app_controller.php file for a central location, which I will get into the next post.

In part 2, existing member were set up as AROs. And with user accounts, we also have to set those up as ACOs. Then those AROs (people) need to have permissions set for the CRUD actions. (Create, Read, Update, Delete). These actions are specific to the ACO, or object they are trying to manipulate. So if a user wants to edit their own account, do they have permission? If a user wants to delete another person’s account, do they have permissions to? With setting up ACLs, this can be checked. But what do we do when a new person signs up for an account? We need to create the code to do this.

In the Users Controller, we need to make sure we use the ACL component is included. So include this in the controller:

class UsersController extends AppController {
	var $name = 'Users';
	var $components = array('Acl');

Also remember that the Auth and Security components are also very powerful components and should be included as well, but the above only shows where to include the components. Now with this in place, we can no address the add (or register) function of the controller.

When a new user registers an account on the site, we want to make sure to give them only access to their own account, and be able to read the other user profiles. The first thing is to create an “add” (or register, I actually prefer that because it just seems to be more logical to me, but I will use the “add” function for this example).

function add() {

}

Now we need to create the basics, or even better, better Bake up the views for the User controller. This helps set the base actions needed to add an account. But here is what some of the included actions should be:

function add() {
	if (!empty($this->data)) {
		// Sanitize the stuff
		$clean = new Sanitize();
		$clean->clean($this->data);

		// Set the data to the model
		$this->User->set($this->data);

		// Clean all of the elements in the data array, Attendee, Organization, and Bill information areas
		$this->data['User']['username']	  = $clean->paranoid($this->data['User']['username'], array('.', '-', '\''));
		// Make sure you clean all the user input values to help clean the input from the user, this is just an example line

		// Set any defaults for the user table, these would be items that are not on the form, ie avatar default, last_login date or ip, just to make sure there is no XSS on those fields

		$this->User->create();

		if ($this->User->save($this->data)) {
			$this->Session->setFlash(__('The User has been saved', true));
			$this->redirect(array('action'=>'index'));
		} else {
			$this->Session->setFlash(__('The User could not be saved. Please, try again.', true));
		}
	}
}

This is just some extensions of the Baked output from the Users controller. I always suggest to sanitze the data, and always set defaults if there are more fields in the table that do not have corresponding inputs. This just helps to cut down on XSS (cross site scripting) and helps to maintain some order of data expected to go in the tables. The next step is to add the ARO and ACO creations for this user.

Every user is an ARO, but they are also ACOs as they may have other users requesting to take action on their accounts. So we need to create the AROs and ACOs for the user right after the create() method:

. . .
$this->User->create();
if ($this->User->save($this->data)) {
	$usr = $this->User->getLastInsertID();

First we need to get the last inserted ID, because this is the user’s new user_id. We need to use that here. Then we need to instantiate the ARO object

$aro = new Aro();

With the ARO object ready to use, we need to create some date to send to the ARO.

$user = array(
	'alias' => $this->data['User']['username'],
	'parent_id' => 4, // member ARO
	'model' => 'User',
	'foreign_key' => $usr
);

We are creating the information we are to put in to the ARO, the alias (which is the username), the parent ID, in this case, the “Members” ARO is aro_id 4, (your parent_id may be different depending on how many AROs you have), the model, which is User in this example, and the foreign key which is the new user id that was just created. Now the Cookbook will say you do not need to put in the alias and the model/foreign_key. But I do because it makes the table easier to read, especially if you are looking at the table doing troubleshooting. It is easier for me, but feel free to find a good method for your own application.

Now take the data, create and ARO and save the data to it.

$aro->create();
$aro->save($user);

Creating the ACO is similar to the ARO, and this is how it would look.

$aco = new Aco();
$aco_usr = array(
	'alias' => $this->data['User']['username'],
	'parent_id' => 2, // User ACO id
	'model' => 'User',
	'foreign_key' => $usr
);

$aco->create();
$aco->save($aco_usr);

Now we have an ARO created, and an ACO, we need to make sure the ARO has certain permissions to the ACO (and its parent). Remember that a few rules for all new accounts is that they can only edit their own account, they can not delete any account, and they can view any account. So we can set these permissions after the ARO and ACO creations.

First we want to set it that they can only edit their own account. We are going to implicitly allow access to only this account.

$this->Acl->allow( array('model' => 'User', 'foreign_key' => $usr), $this->data['User']['username'], 'update' );

By setting the permission this way, it is only granting access to their own account in order to edit or update. If this ARO tries to update another account, it will not have the permissions needed to do so. Now we need to deny the delete action for all User ACOs.

$this->Acl->deny( array('model' => 'User', 'foreign_key' => $usr), 'Users', 'delete' );

This will deny all delete actions for this ARO. By specifying the “Users” ACO, we are safeguarding the delete action. This not only denies the delete action from happening on the “User” ACO itself, but all of its child nodes, or in other words, any ACO that has the “Users” ACO as it parent. Thus, this newly registered user can not delete any account in the system.

Here is it in its entirety:

function add() {
	if (!empty($this->data)) {
		// Sanitize the stuff
		$clean = new Sanitize();
		$clean->clean($this->data);

		// Set the data to the model
		$this->User->set($this->data);

		// Clean all of the elements in the data array, Attendee, Organization, and Bill information areas
		$this->data['User']['username']	  = $clean->paranoid($this->data['User']['username'], array('.', '-', '\''));
		// Make sure you clean all the user input values to help clean the input from the user, this is just an example line

		// Set any defaults for the user table, these would be items that are not on the form, ie avatar default, last_login date or ip, just to make sure there is no XSS on those fields

		$this->User->create();
		if ($this->User->save($this->data)) {
			$usr = $this->User->getLastInsertID();

			$aro = new Aro();
			$user = array(
				'alias' => $this->data['User']['username'],
				'parent_id' => 4, // member ARO
				'model' => 'User',
				'foreign_key' => $usr
			);

			$aro->create();
			$aro->save($user);

			/*****************************/
			$aco = new Aco();
			$aco_usr = array(
				'alias' => $this->data['User']['username'],
				'parent_id' => 2, // User ACO id
				'model' => 'User',
				'foreign_key' => $usr
			);

			$aco->create();
			$aco->save($aco_usr);

			// Set the permissions
			$this->Acl->allow( array('model' => 'User', 'foreign_key' => $usr), $this->data['User']['username'], 'update' );
			$this->Acl->deny( array('model' => 'User', 'foreign_key' => $usr), 'Users', 'delete' );

			$this->Session->setFlash(__('The User has been saved', true));
			$this->redirect(array('action'=>'index'));
		} else {
			$this->Session->setFlash(__('The User could not be saved. Please, try again.', true));
		}
	}
}

So that will set a new ARO and ACO for a new user. You would follow the same path for an event, or group, but you would only set a new ACO, and the permissions as needed, based on requirements. But this is not the only thing to do. We still need to check these permissions. As it stands right now, any user can edit or delete any other user, because we have not included the ACL check yet. So to demonstrate this check, we will use the Edit function as an example.

In the edit function, there is an ID passed to the function. This is the ID of the account to be edited. We need to check if the currently logged in user has the permissions to edit this account. We do that by doing an ACL check.

$this->Acl->check(array('model' => 'model_name', 'foreign_key' => "id of logged in person" "alias of ACO", "action requested");

So for this example, it is the User ACO we are wanting, more specifically the user account requested to be edited, and the action is (of course) update. So the first thing is to get the alias of the user to be edited

function edit($id = null) {
	$info = $this->User->read(null, $id);
}

This will pull the id into an array called “info” and we are looking for $info['User']['username']. Remember that your version may vary based upon the table info you have. Now we can do a check based on the currently logged in user, and in this example I am using the Auth component to get that.

if ( $this->Acl->check(array('model' => 'User', 'foreign_key' => $this->Auth->user('user_id')), $info['User']['username'], 'update') ) {
	// Do the edit stuff here
} else {
	$this->Session->setFlash(__('You are not allowed to edit this user.', true));
	$this->redirect(array('action'=>'index'));
}

This will check the currently logged in user to see if they have update permissions on the specified user_id’s ACO. If they do have permission, then it will go through the edit actions, checks, etc. If they do not, it bypasses that altogether and kicks them back to the index view with a message.

The same can be done for the delete action

function delete($id = null) {
	$info = $this->User->read(null, $id);

	if ( !$this->Acl->check(array('model' => 'User', 'foreign_key' => $this->Auth->user('user_id')), $info['User']['username'], 'delete') ) {
		// Do the delete stuff here
	} else {
		$this->Session->setFlash(__('You are not allowed to DELETE this user.', true));
		$this->redirect(array('action'=>'index'));
	}
}

Now this is just a simple example, and this same type of idea can be done for events, editing events, viewing events, etc. The same goes for groups and any other type of application where a permission check is needed.

Now, is my soap-box time. Why use ACLs at all? Wouldn’t a simple “level” table be enough to create this same type of effect? Yes and no. Remember that the right program for the job is determinant upon the job requirements. If an application is going to be used for a small purpose, and maybe you only will have 50 people at the most in a calendar application, then an ACL may be going a little overboard. However, if you have 50 people who are part of different groups, and based on group membership can do different things on the application, and the tasks may change from person to person based on work load, then an ACL may take some of the stress of of doing this type of thing.

Remember that an ACL is a great way to keep permissions in check with little human overhead involved. But sometimes the job requires that human overhead is needed, sometimes not. ACLs are great, and I use them frequently on big jobs. For the smaller jobs, I do not. But after this, hopefully you know better about what an ACL is, and how to use one in an application.

To go along with the idea of the last post, the application has a few different areas: Users who are members of groups, Groups which have users as members, and Events that belong to either the user or the group. Since the creation of ACOs and AROs are basically the same for each area (Users, Groups, Events), I will detail some code for the Users area making use of ACLs.

The first thing we need to do is create an ARO grouping and an ACO grouping. Remember that AROs are the requester of an object. In this example, we can think of them as people. And people have different types of roles, which is what we need to create for the people. In this example application, there will be site admins (Admins), group leaders (Leaders) and regular members (Members). So we need to create this type of ARO. We can do this in a controller, and a page, or we can do this via the command line.

If you create the AROs and ACOs via a controller, it would be done this way:

$aro = new Aro();
$groups = array(
	0 => array('alias' => 'Admins'),
	1 => array('alias' => 'Leaders'),
	2 => array('alias' => 'Members'),
);

foreach($groups as $data)
{
	$aro->create();
	$aro->save($data);
}

Instantiate the new ARO object, then set up information for the ARO. Then iterate through the array in a foreach loop. You can do the same for the ACO parents that need to be created. The ACOs in this example are similar to our models. There are events, users, and groups. To create those, follow the same pattern as above, only make sure to use the “Aco()” object. However, an easier way (at least I think so), is to use the command line interface (cli) to create these.

To use the cli for this, you will need to be logged in via “SSH” to the server, or connected via shell, or however else you choose to connect. The command to create the ACOs and AROs is:

# cake acl create aro (parent) (node)
# cake acl create aco (parent) (node)

So if I was going to create the groups for the parent AROs, I would do the following:

# cake acl create aro Members admin

NOTE: If you have not set up the CakePHP console paths according the Cookbook specifications, then you may have to use this command line a little different call. I always suggest to run the console from the App folder. From there, you can run the following:

# php ../cake/console/cake.php acl create aro Members admin

I do suggest you set up the console to work without this, but if for some reason you are unable to, this can work as well.

So this will set up each parent ARO and ACO. Now we need to address the users. If there are already users in the system, then we can use the cli to update them and add them to the ARO table. However, users a different bunch, and this is why I choose to use the example on them instead of events or groups. Events and groups are both objects which are requested by users. But users, they are different. For example, if a user with the username of “test1″ exists, and logs in, and then sees another account, let’s say that account username is “answer1″, we do not want “test1″ to be able to edit this account. However, we would want an administrator to have this ability. So we need to lock down edit permissions from “test1″ so that he can only update his own account, and we want to be able to give administrators access to edit any User account. So now users are not only an ARO, but they become an ACO as well. And we need to give (or deny) permissions to any user based on who they are.

So lets say we have 3 users already in the system. “BigMan1″, and administrator, “Newbie” and “Lilie” both regular members. We want to be able to create an ARO for each of them, and then create an ACO for each of their accounts, and then give them permissions. To create the ARO and ACO for each account (with showing the return from the console):

$ cake acl create aro Members BigMan1
New Aro 'BigMan1' created.

X-Powered-By: PHP/5.2.6
Content-type: text/html

$ cake acl create aco Users BigMan1
New Aco 'BigMan1' created.

X-Powered-By: PHP/5.2.6
Content-type: text/html

Now we can follow this for the other two and they would be created. Now we need to give them permissions. The admin should have access to edit any User account, delete any user account except for their own, and be able to view any User account. To grant permissions, the command is:

$ cake acl grant admin aro aco  action

The action can be one of the four CRUD members or “all”. We are going to start with the admin user, because they will get access to all Users.

$ cake acl grant BigMan1 Users update
Permission granted.
X-Powered-By: PHP/5.2.6
Content-type: text/html

$ cake acl grant BigMan1 Users delete
Permission granted.
X-Powered-By: PHP/5.2.6
Content-type: text/html

$ cake acl grant BigMan1 Users read
Permission granted.
X-Powered-By: PHP/5.2.6
Content-type: text/html

Now there is a problem here. The Admin can delete his own account right now, because we have given him permissions to delete and User account (parent ACO = Users). We do not want him to delete his own account, so we need to deny him permission. This is done very similar, only instead of “grant”, it is “deny”.

$ cake acl deny BigMan1 BigMan1 delete
Permission granted.
X-Powered-By: PHP/5.2.6
Content-type: text/html

In the above example, we are doing an acl command, denying permissions for ARO BigMan1 on ACL BigMan1 for the delete action. In the previous example where we granted him permissions, we set the ACO on the parent, so that any child nodes would inherit the same permissions. But on this deny, we want to deny only for a child node.

Now, when we grant access to other users who are not admins, we would do this on the child nodes. So lets say that users can read any User account, only edit their own, and never delete their own account. So we would do that as:

$ cake acl grant Newbie Newbie update
Permission granted.
X-Powered-By: PHP/5.2.6
Content-type: text/html

$ cake acl deny Newbie Users delete
Permission denied.
X-Powered-By: PHP/5.2.6
Content-type: text/html

$ cake acl grant Newbie Users read
Permission granted.
X-Powered-By: PHP/5.2.6
Content-type: text/html

This will grant “Newbie” access to read any User account, update their own account, and denied being able to delete any account.

So that does it for the existing users. But now what about any new user that registers on the site? That will be covered in part 3, and will show some of the true power of the ACL when used in applications.

First is to understand what an ACL really is. The Cookbook has a good page explaining this type of concept. I highly recommend reading through this page. The whole concept behind this ACL can be divided in three parts:

• ACO – Access Control Object, object that is being requested
• ARO – Access Request Object, object that is putting in the request
• ACL – Access Control List, determines if an ARO can access an ACO.

In the Cookbook, they have a very good call out about the ACL, it is not authentication. No matter what code base, or platform you are on, never mistake this. The ACL verification only happens after the person logs in. They can be very powerful together, but authentication must happen first.

The next thing to understand is the way an ACL would look in a matrix. Again, the Cookbook provides a great example of this. The one thing that I would rather prefer, but understand why they do this, is the use of the example. Sure, we all like movies, and the Lord of the Rings is a great way to really explain different things, but it may be hard to switch that over to the real world of coding. So for this entry, I am going to use as an example, and Event Calendar.

In this Event Calendar, here is the breakdown: there are events, there are groups, there are users. Each user is going to be a member of a group. A group will have a “leader” who can add, edit or delete group events. A group will also have an “editor” who will be able to add or edit group events. And the default group membership is one who can only view group events.

• Groups
• – Leader
• – - Add, edit, delete group events
• – - View all group events
• – Editor
• – - Add, or edit group events
• – - View all group events
• – Member
• – - View all group events

Users will be anyone who creates a login to the application. Of course there will be a “site admin” who can add, edit, delete to any user account except their own. They can assign a user to a group, or remove memberships. The group leader can add or remove memberships to their own group only. They can not add, edit or delete user accounts. The default user can edit their own account, and request for the account to be deleted (they can not delete their own account).

• Users
• – Site Admin
• – - Add, edit, delete all user accounts (except the site admin account)
• – - Add, or remove users from any group
• – Leader
• – - Add or remove users from their own group only
• – Users
• – Sign up for an account, edit only their profile
• – request to be a member of a group

Events can be either a group event, or an individual event. Group members can see group events, and an individual event is only available to be viewed by the user who entered the event.

• Events
• – Group Events
• – - Viewable by members of the group
• – Individual Events
• – - Viewable only by the user who entered the event

To put this in a “use case” scenario, here are four examples:

Case 1: Username “MotoCrash” is a registered user of the site. He is also a group leader of the “ProFootball” group. He is able to update membership of the group, and is able to edit the different events for the group calendar. There are some events he has had to delete. He often updates his own account with a new avatar image. He can view all of the group events to determine if any of them need to be edited.
ARO = “MotoCrash”
ACOs = Groups, Events, Users

Case 2: Username “FootballNut” is a registered user of the site. He is a member of two (2) groups. He is a regular member of the group named “ProFootball” and a group leader of “PopWarnerBall”. He is able to see events in both groups, but is only able to add, edit, or delete events in the “PopWarnerBall” group. He adds his own events for personal uses that only he is able to see.
ARO = “FootballNut”
ACOs = Groups (2 checks), Events

Case 3: Username “Angel” is a regular member. She is not part of a group as of yet, but posts events to her own personal calendar. She is able to edit her account, adding a new signature line every month. She is able to view her own events. She is an avid football fan, but is unable to see events for the ProFootball group.
ARO = “Angel”
ACOs = Groups, Users, Events

Case 4: Username “Admin” is a the site admin. They are able to do all actions in any group, and able to update any memberships, or add, edit or delete accounts. They are not able to delete their own account.
ARO = “Admin”
ACOs = Groups, Events, Users, Administation

I hope this has been helping to better understand ACLs. In order to really delve into this topic, and separate the different areas, I am finishing this post here. I am going to post another one that gets into the code of setting up the tables (acos, aros, aros_acos), and then the coding portion of the ACLs, like when a new user is created, group membership changes, or how to validate on the ACL based on the logged in user.