I’ve been working on content for my CakeFest workshop this year, and thought it would be interesting to see a commonly used authorization pattern implemented as an extension to CakePHP’s authorization system. The pattern I wanted to implement was ‘sudo mode’. Often this pattern is used in applications that have longer session duration.

I have been following the Webauthn standards and browser support since the early days of FIDO compatible keys. I strongly believe that hardware keys are our best path forward to provide phishing resistant, easy to operate authentication, that doesn’t compromise on privacy.

In the next major release of CakePHP we’re going to be removing the AuthComponent. This component and its helpers have been part of CakePHP since the 1.2 days, but their time has come to an end. Over the years, AuthComponent has become a complex and difficult to extend piece of CakePHP. In its wake, we’re promoting two new plugins.

CakePHP uses salted sha1 hashes for passwords by default, and has for a while. There has been some talk on the mailing list lately of switching the default hashing to something more secure, such as bcrypt. I think this is a great idea, and will find its way into CakePHP in a future release. Providing a reasonanle upgrade experience is the biggest problem to solve, if the default hashing strategy was to change.

Over the long Ontario weekend, I took some time to update Acl Extras. It now works with plugins and the improvements made to the Auth + Acl for 1.3. The master branch contains the CakePHP 1.3 compatible version. While the 1.0.0 tag, and 1.0 branch are still compatible with CakePHP 1.2.

By now you already know or should know about CakeTestCase::testAction() and the wondrous things it can do. However, testAction has a few shortcomings. It can’t handle redirects, it doesn’t let you use the power of Mocks, and its impossible to make assertions on object state changes. Sometimes you need to do things the hard way, stick your fingers in the mud and work it out.

By now you’ve got an awesome Acl and Auth controlled app running. However, making navigation menus is a pain with dynamic, and variable permissions. Outside of making menu elements for each type of Aro and including them in your layout, there currently aren’t many options (at least none that I’m aware of). I was faced with this exact problem a while back, and couldn’t find a suitable solution, so I made one.

In my previous Auth and Acl tutorial I mentioned that I wasn’t including a way for users ARO to be automatically updated when a User’s group was updated. Well ‘hepper’ posted a patch to the AclBehavior in the comments to that article.

Continuing in my previous vein of ACL related topics. I’ve got another handy addition to the ACL user’s toolbox.

If you are looking for part one go here

In the last article we created the basic models, controllers and views for our Auth and Acl controlled app as well as initialized the Acl tables. We also bound our groups and users to the Acl through the use of the AclBehavior.

Now, there are many tutorials out there for Auth and ACL in CakePHP. However, none of them (as far as I know of) cover putting together Auth and ACL from beginning to end. That is what I’m going to do in this article. I am splitting the article into two parts; the first about setting up our app and getting the Aros running, the second on building Acos and putting it all together.