One of the things that I found most confusing about implementing the Auth component and ACL was their precise relationship, how they hung together, what one was and the other wasn’t or more specifically what one did and the other didn’t.

While conceptually not complicated – the Auth Component is something that identifies a user whereas the ACL component is something that takes that knowledge and says “what does this identified user have access to” – they seem (at first) so intermeshed in the “Automagic” functions of CakePHP that it can be difficult to establish what is causing what to happen.

I found this particularly so when, having not gone through the Simple-Acl-controlled-Application tutorial kindly provided by the CakePHP team, I dropped the Auth component into my components list and lo and behold I was required to authenticate against actions I had wanted protected.

It wasn’t until reading this article and doing a bit of experimenting i realised that while it was definitely “Authenticating” it was not “Checking access” so none of my ACL stuff was kicking in at all.

An example of how the two functions seem intermeshed is the allowedActions function that is specified in the beforeFilter:

$this->Auth->allowedActions = array(‘*’);

This is (as the method path shows) a function of the Auth component, but it relates to Access, in this case the actions of the controller.  This is an important function to understand, this tells the AuthComponent to allow PUBLIC access to all actions, you can of course provide a specific array of actions here as well.  The important thing to understand is that “public” is just a default state given to a non authenticated user, it is not a specific group you need to create and assign by default (which is the case in some authentication systems I’ve seen).

So remember that while a user can be “authenticated” that is, they are known to the system they are not necessarily being  checked against their access profile,  $this->Auth->allowedActions can confuse matters if you’re not careful because it can suggest that the authenticated person does or doesn’t have access to something (because they get redirected to the login page).

When working out what is tripping up a security response, use this handy guide to Debugging CakePHP Auth component which can tell you what is being validated against and thus if it is your dodgy ACL setup or just the default settings in the Auth component that are causing any problems.

What is the difference between the Auth component and the ACL component in CakePHP?

User password is "double hashed on edit when using the Cakephp Auth component

I found a good basis for a resolution to this issue here . It wasn’t perfect for me but did a nice job of explaining a problem I had with hashed values. I have provided a modified solution below that meets my requirements more specifically (that is to allow password changes only when a password confirm is provided on edit, while requiring a password on add).
A problem I had encountered along the way was due to me not understanding the hash function, I couldn’t get the two hash values to match, this problem is highlighted in the post “Manually hashing password and password validation in CakePHP“:

Security::hash($this->data['User']['passwd'], null, true);
This line makes the password readable by the Auth component, and that in turn removes the need of creating your own. Take a look at the API reference of Security::hash() and you will see that the third parameter is very important, as it tells the hash function to use the “Security.salt” value in the hashing process. In any case, if you need to hash something and be compatible with the Cake’s own Auth and Security, this seems to be the right way.

So make sure you include the second and third parameters of the security function whichever solution you implement.

Below is my version of the code, I have essentially reversed the validation process as I wanted it to only execute if a password confirm was provided (that is the validation wouldn’t be tripped up unless they specifically wanted to change the password, and if the password field itself was blank then nothing should happen ever).

Taken from user.php (the model)

    function __construct()
    {
        parent::__construct();   

		/*
		 * Validate on the password field not the password confirmation field
		 * This ensures that if we enter blank in both then nothing is triggered
		 * or blank on the confirmation field only then it is rejected using validatePasswdConfirm
		 */
        $this->validate = array
        (   

            'passwd' => array
            (
                /* snip other rules */
                'match' =>
                array
                (
                    'rule'          => 'validatePasswdConfirm',
                    'required'      => false,
                    'allowEmpty'    => true,
                    'message'       => __('Passwords do not match', true)
                )
            ), 

	 /*
	 * On creation when we always want a password, have the form use a normal
	 * password field and have it validated against it's own special "empty" check
	 * that is '' that has been hashed (automagically by cake)
	 */
            'password' => array
                (
                    'rule'          => 'validateHashedPassword',
					'required'      => false,
                    'allowEmpty'    => false,
                    'message'       => __('You must submit a password', true)
                )
        );
	}

   function validateHashedPassword($data)
    {
		if ($data['password'] == Security::hash('', null, true))
        {
            return false;
        }   

        return true;
    } 

   function validatePasswdConfirm($data)
    {
		if (isset($this->data['User']['passwd_confirm'])&&
			$this->data['User']['passwd'] <> '' &&
			$this->data['User']['passwd_confirm'] !== $data['passwd']
			)
        {
            return false;
        }   

        return true;
    }   

	function beforeSave() {
	    /*
	     * Ensure that there is a value for the password,
	     * field it should be ignored if they are not
	     * providing a value (i.e. no update should take place)
	     */
		if (isset($this->data['User']['passwd']) && $this->data['User']['passwd'] <> '')
	    {
	        $this->data['User']['password'] = Security::hash($this->data['User']['passwd'], null, true);
	        unset($this->data['User']['passwd']);
	    }   

	    if (isset($this->data['User']['passwd_confirm']))
	    {
	        unset($this->data['User']['passwd_confirm']);
	    }   

	    return true;
	}

Just to be clear too here is my add/edit form (I combine them to save duplication), admin_edit.php:

create('User');?>



	input('id');
		echo $form->input('email');
		//App::import("Vendor", "dbug2");new dbug2($this->data);

		if(empty($this->data['User']['id'])){
			echo $form->input('password', array('value' => '','autocomplete'=>'off'));
		}else{
			echo $form->input('User.passwd', array('label' => 'New password','value' => '','autocomplete'=>'off'));
			echo $form->input('User.passwd_confirm', array('type' => 'password','label' => 'Confirm new password','value' => '','autocomplete'=>'off'));
		};
		echo $form->input('firstname');
		echo $form->input('surname');
		echo $form->input('group_id');
	?>
	

end('Submit');?>

Notice too the attribute:

'autocomplete'=>'off'

This just prevents the field from being auto populated which I was experiencing while testing.

Introduction

If you’re anything like me by the time you’ve got to this guide you have probably read about a million interesting but very issue specific pages on setting up elements of the Auth Component in CakePHP.  For such an integral element of the system I found it surprisingly difficult to really understand all of the elements.  Getting it working was one thing,  but really understanding the “Automagic” functions behind the scenes, what happened where and what would happen if I changed something took a lot of research.

So this guide attempts to bring together the results of that research.  It is a combination of  the “must reads” , a list of problems and solutions that I encountered when implementing stuff from them, a FAQ section (rather a Q&A of the things I wanted to know along the way) and a general tips section for things that should make your life a bit easier.

The guide will continue to evolve as I discover more but if you have any suggestions or questions please submit a comment below so it is available to all.

Required reading

These links are required reading if you want to get to grips with the Auth component AND ACL.  I can’t stress enough how important it is to have read these and done them line by line before you start looking for answers elsewhere, without these examples the Auth component and ACL will be a little too black box.

• How ACL works (from the CakePHP Book)
• A Simple ACL controlled application (from the CakePHP Book tutorials)

Common problems with CakePHP Auth component and their solutions

• DbAcl::allow() - Invalid node [CORE\cake\libs\controller\components\acl.php, line 325]

CakePHP Auth Component – FAQ

• Cake PHP Auth Component Frequently Asked Questions (FAQ)
• What is the difference between the Auth component and the ACL component in CakePHP?
• User password is "double hashed on edit when using the Cakephp Auth component

Tips and and tools

Debuging ACL in CakePHP

Some handy tricks for seeing what is going on under the hood, this can be surprisingly tricky when things are happening automagically.

• Debugging CakePHP Auth component
• Session variables available when using CakePHP auth component

Managing ACL in CakePHP

One of the complicating factors in managing your ACL setup is the derth of good management tools available.  The data required is fiddly and doesn’t lend itself to hacking around in the database to get things going because in my experience you just make yourself more confused than ever.

Probably the best management tool I found was:
http://bakery.cakephp.org/articles/view/acl-management-plugin

It’s not perfect, but it’s a solid tool that will speed up some of your management functions.

Handy functions that play nicely with the Auth Component

Keep track of modifications to your records automatically, these mods save time but also reveal some interesting concepts behind the Authcomponent.  Pay close attention to Comment 5 “Brett H Says” which explains an issue you’re likely to encounter using this if you’ve set up the auth component using the standard configuration.

• Automagically setting user ID of record creator and modifier in CakePHP 1.2

Other reading

Aran Johnson has done an excellent series of examples and tutorials on the CakePHP auth component here.  I found these when I was about half way through writing this guide so there is some duplication of course, but hopefully between the two you will find everything you need.

Ok, so here are some tricks for debugging the cakePHP auth component in no particular order, they are not a guide to setting up the CakePHP auth component per se so take a look at those for more general set up information:

Debugging the controller and action being requested by the Auth component

in the beforeFilter() of app_controller.php put:

$this->Auth->authError = sprintf(__('You are not authorized to access that location %s/%s .',true),$this->name,$this->action);

This should be alongside your settings for $this->Auth->loginAction and $this->Auth->loginRedirect for example – assuming you have correctly set up your login form to display $session->flash(‘auth’); then it will show you what was rejected by the Auth component.

$session->read(‘Auth.User’)

E.g. using the superb dBug tag (if you’re not using it you should be, I don’t even bother with other dump functions now):

App::import(“Vendor”, “dbug2″);new dbug2($session->read(‘Auth.User’));

As an aside, anyone who is NOT using the  php dBug tag which mimics the equally excellent CFdump tag in Coldfusion, you should be!