I am using the Auth component in my User model. I have allowed register, resetpass, and index. So when I go to view a user’s detailed profile, there is that message: “You are not authorized to access that location.” Which is a fine message and all, but I want it to be site specific, and also controller specific. So the Users controller will have a separate Auth error message than the Calendars controller. So here is what I did.

In the Users controller, I built a beforeFilter function. I set my authorized actions, set redirect to false. I also set a session level variable with the Auth, then I set the error message. There are a couple of messages you can set for the Users controller. You can set the loginError and the authError. The loginError will be the error when the user logs in and is unable to for whatever reason. The authError is what the user will see when they try to perform an action that is not allowed by them, whether it is because they are not logged in (as in my case) or you are using Auth to “authorize” an action.

So here is what it would look like:

function beforeFilter() {
	parent::beforeFilter();

	$this->Auth->allow('register', 'index', 'resetpass');
	$this->Auth->autoRedirect = false;
	$this->Auth->authorize = 'controller';
	$this->set('my_id', $this->Auth->user('user_id'));
	$this->Auth->authError = "Please log in first in order to preform that action.";
}

So when you want to change the standard Auth error message, just remember to set the “authError” to whatever message you would like. Happy Labor Day!

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.

CREATE TABLE IF NOT EXISTS `users` (
	`user_id` int(11) NOT NULL auto_increment,
	`username` varchar(25) NOT NULL,
	`password` varchar(250) NOT NULL,
	`full_name` varchar(250) NOT NULL,
	`email` varchar(250) NOT NULL,
	`remote_address` varchar(16) NOT NULL,
	`last_login` datetime default NULL,
	`last_login_ip` varchar(16) default NULL,
	`created` datetime NOT NULL,
	`modified` datetime default NULL,
	PRIMARY KEY  (`user_id`),
	UNIQUE KEY `username` (`username`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

In this table, there is a lot you really do not need, but here is the breakdown: ‘user_id’ is needed for my purposes, ‘username’ and ‘password’ are named as such to be able to use the Auth component methods. The other fields are for personalization (full_name and email). The next three are just for simplistic CYA that should always be good practice, grap the registered IP address, date the user last logged in and the IP they logged in from. Is this a foolproof way of CYA? No. But it starts you out on the right track. The last two I always put in all of my tables, as CakePHP updates those automatically, so this also helps to track when created and when changed.

Now that the table is done, we need to provide some quick validation for registration and such. In the model, the code should look similar to this:

var $name = 'User';
var $primaryKey = 'user_id';
var $validate = array(
	'username' => array(
		'alphaNumeric' => array(
			'rule'		=> 'alphaNumeric',
			'required'	=> true,
			'on'		=> 'create',
			'message'	=> 'Username must be only letters and numbers, no special characters'
		),
		'between' => array(
			'rule' 		=> array('between', 5, 20),
			'on'		=> 'create',
			'message'	=> 'Username must be between 5 and 20 characters',
		),
		'isUnique' => array(
			'rule'		=> 'isUnique',
			'on'		=> 'create',
			'message'	=> 'This username is already taken. Please choose a different one.'
		)
	),
	'email' => array(
		'rule'		=> array('email', true),
		'required'	=> true,
		'message'	=> 'Please provide a valid email address'
	),
);

The data validation is a topic for another post, and the Cookbook has a good entry for this as well. In this example, there is multiple validations for the username, and one for the email. We want the username to be only alphanumeric, between 5 and 20 characters in length, and it needs to be unique. The email just needs to be a valid email address. Each validation rule has its own error message. But we have provided simple validation for the model.

Now it is time to create/update the controller. If you have Baked the controller, then you have 5 actions, index, add, edit, delete, view. I am not particularly fond of having a “register” action named “add”, so I changed this around. Remember that if you are using the Auth component to allow this in the beforeFilter() function.

$this->Auth->allow('register');

Now in my “register” function, I started off with checking if the data set is empty. And if you Baked the controller, most of this should be in there already. The register function will have two main parts, if the form is filled out and if it is not/has errors. With using the Auth component, it is important to remember a basic part of the Auth with passwords, it hashes the passwords for you and includes the SALT string in the config file. So I will point this out right now. YOU MUST RESET THE PASSWORD FIELD IF YOU DO NOT WANT EMPTY STRINGS FOR PASSWORDS. This includes if you are using data validation for this field. Auth automatically appends whatever is in the password field and appends the SALT. So if someone leaves it blank, Auth will still append the SALT and it will never be blank. The best way to check this is with AJAX/javascript for the field on the form level, not the processing level. On the processing level, if the form is blank, or contains errors, clear the password field.

function register() {
	if (!empty($this->data)) {
		// code to be put here
	}

	$this->data['User']['password'] = ''; // reset the password field
}

This now checks for the form being filled out, and if not, resets that password field. (As a note, it is always best to have the password verified by entering this twice, but for right now, we are skipping this). If the form is empty, we reset data, and have the user fill out the form again. If not, we start to look to see what data we have to work with. I always suggest to use the Data Sanitizer component to help clean up the fields. This helps ensure the data will not empty your tables or other problems occur (not all web surfers are harmless). With the sanitation, set the data to the model so the validation rules can help out.

function register() {
	if (!empty($this->data)) {
		$clean = new Sanitize();
		$clean->clean($this->data);
		$this->User->set($this->data);
		// Sanitize the data using this only as an example, but all fields that require the user to type should be included
		$this->data['User']['username'] = $clean->paranoid($this->data['User']['username']);
	}

	$this->data['User']['password'] = ''; // reset the password field
}

Now we need to check those validation rules, and CakePHP has a perfect function to help do this. By using the $this->MODEL->validates() function, it will check any validation rules that have been specified for the model. If there is errors, then it kicks the user back to the form with those error messages. If it does validate, then then we can proceed to create the account.

function register() {
	if (!empty($this->data)) {
		$clean = new Sanitize();
		$clean->clean($this->data);
		$this->User->set($this->data);

		// Sanitize the data using this only as an example, but all fields that require the user to type should be included
		$this->data['User']['username'] = $clean->paranoid($this->data['User']['username']);

		// Check for validation rules
		if ($this->User->validates()) {
			// All validation rules have been satisfied, so we need to check this in to the table
                        $this->User->create();

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

	$this->data['User']['password'] = ''; // reset the password field
}

First we check to see if the form has been filled out, and sent. If it has, we sanitize the data, then validate it. If it validates, we create the record. If the record can not be created, for whatever reason, it kicks them back. If the data can be saved, and the record is created, it then redirects them back to the “login” page. This is just a simplistic registration form. We can extend this to use a full blown profile table, add more sanitation, and more validation. But for right now, this is good. We now need to allow them to login. And the Auth component makes it easy.

We can make it as easy as we need, or as hard as we need. With using the Auth component, all we would really need to do is

function login() {
}

You would still need to create the view for it, having the username and password fields there, but if you would like more info in the Session, then there is just a little more to do. The first is to check to see if the login form has been filled out, then check for it to be blank, sanitize the data, and now we get to some meat here. With the Auth, we can grab other fields and set them to be used in the Session

function login() {
	if ($this->Auth->user()) {
		if (!empty($this->data)) {
			$san = new Sanitize();
			// Sanitize the input of items we do not know what the end user put in.
			$this->data['User']['username'] = $san->paranoid($this->data['User']['username']);

			// Grab the data from the User table and set them to the cookie array
			$cookie = array();
			$cookie['user_id'] = $this->Auth->user('user_id');
			$cookie['full_name'] = $this->Auth->user('full_name');
			$cookie['ast_login'] = $this->Auth->user('last_login');
			$cookie['last_login_ip'] = $this->Auth->user('last_login_ip');

			$this->Session->write('Auth.User', $cookie);
		}
	}
}

The Session->write() method will write these to the Session with the cols/vals in a foreach loop. So name the elements in the array with something useful if you intend to use them later so that you can recall them. The CakePHP API documentation provides great information on the write() function, but real quick, it is the name, then value. The next part I added to this was to update the User table with the info:

$update['User']['user_id'] = $userid;
$update['User']['last_login'] = $this->data['User']['last_login'];
$update['User']['last_login_ip'] = $this->data['User']['last_login_ip'];
$this->User->save($update, false, array('user_id', 'last_login', 'last_login_ip'));

After successful login, we can redirect using the Auth redirect, which is handy to redirect users back to pages where authentication was needed to get in.

$this->redirect($this->Auth->redirect());

One other thing I added in, just because I can not stand forms and logins that allow you to log in even if you are already logged in, is to check to see if they are logged in. If they are logged in, and try to log in again, I send them back to the home page, with a message reminding them of their current status. I also clear out the Auth message in case anything is lingering in there.

if (empty($this->data)) {
	// Check to see if they are logged in
	if (isset($_SESSION['Auth']['User']['username'])){
		$this->Session->setFlash(__('You are already logged in. ', true));
		$this->redirect(array('action' => 'index'));
	}

	// Perform other checks on the empty data and set up the form.
	$cookie = $this->Session->read('Auth.User');
	if (!is_null($cookie)) {
		if ($this->Auth->login($cookie)) {
			//  Clear auth message, just in case we use it.
			$this->Session->del('Message.auth');
			$this->redirect($this->Auth->redirect());
		}
	}
}

Seems like too much? Well, with my long-winded explanations, yes, but it is quite simple and quick when you get to coding it, and one more time, the entire login function

function login() {
	if ($this->Auth->user()) {
		if (!empty($this->data)) {
			$san = new Sanitize();
			// Sanitize the input of items we do not know what the end user put in.
			$this->data['User']['username'] = $san->paranoid($this->data['User']['username']);

			// Grab the data from the User table and set them to the cookie array
			$cookie = array();
			$cookie['user_id'] = $this->Auth->user('user_id');
			$cookie['full_name'] = $this->Auth->user('full_name');
			$cookie['ast_login'] = $this->Auth->user('last_login');
			$cookie['last_login_ip'] = $this->Auth->user('last_login_ip');

			$this->Session->write('Auth.User', $cookie); 

			$update['User']['user_id'] = $userid;
			$update['User']['last_login'] = $this->data['User']['last_login'];
			$update['User']['last_login_ip'] = $this->data['User']['last_login_ip'];
			$this->User->save($update, false, array('user_id', 'last_login', 'last_login_ip'));

			$this->redirect($this->Auth->redirect());
		}
	}

	if (empty($this->data)) {
		// Check to see if they are logged in
		if (isset($_SESSION['Auth']['User']['username'])){
			$this->Session->setFlash(__('You are already logged in. ', true));
			$this->redirect(array('action' => 'index'));
		}

		// Perform other checks on the empty data and set up the form.
		$cookie = $this->Session->read('Auth.User');
		if (!is_null($cookie)) {
			if ($this->Auth->login($cookie)) {
				//  Clear auth message, just in case we use it.
				$this->Session->del('Message.auth');
				$this->redirect($this->Auth->redirect());
			}
		}
	}

}