Skip to main content

Role based authentication in Cake 2.x

I do not like reinventing the wheel so really just want to build on existing tutorials and provide some background information and experience.

 Firstly make sure you understand the difference between ACO and ARO. To put it in very simple terms an ACO is something that is protected by ACL and an ARO is something that uses ACL to access the ACO.

 It might help to think of ARO as users (groups) and ACO as controller actions. You will be marking your user and group models as requester objects and setting ACO on controller actions across the board.

The Cake manual really is good in explaining the concept of ARO, ACO, ACL. Please make sure you read it and understand it before continuing.  Unless you understand what ARO, ACO, and ACL mean at this point the rest of this post will make no sense.

Please RTFM before continuing.

Okay, now read through the Cake page that introduces the ACL shell (here). Ignore the sections "Create and delete nodes" and "Grant and Deny Access". We will be using tools to do these tasks since manually assigning permissions for even a medium sized project (20 models) would be unmanageable - especially if you are using a feature driven Agile approach.

Read and preferably try out the tutorial found on the Cake book site (here). Following this tutorial will give you a role based authentication system. Since we are predominantly interested in Role Based Authentication please make sure that you follow the instructions regarding "Group-only ACL" (here).

Still with me? Okay - I typically use a feature driven Agile approach when developing. CakePHP really lends itself to this development methodology. BUT it does mess around a bit with ACL when you need to add new models and controller methods. So what's the fix?

Well, in my opinion, the AclExtras plugin (available here) that the tutorial I linked to earlier is an indispensable tool. By using it to sync the ACO table (read the tutorial) you can quickly create/recreate the ACO tree.  Now you should understand why I told you to ignore the section "Create and delete Nodes" from the Shell Manual.

Go back to the page about the ACL shell (here). At the bottom of the page there are instructions to output the tree. I personally like to output it into a text file and store it in my documents folder. Not only is it useful to have a list of the ACO's but it really helps in creating the initDB method in the Users controller (see the tutorial).

 Please don't make the mistake of making every model an ARO. Only the User/Group tables need to be ARO. The tutorial doesn't explicitly say this and I remember the first time I worked with ACL I made this mistake. Do not copy and paste the ActsAs requester into each model!

Development is never static (unless you are using a Waterfall approach in a legacy environment like Cobol or Fortran). So working with ACL in CakePHP will require some tweaking as you go along.

 Fixing the ARO table is relatively simple. There are a couple of ways to fix it:

1) Truncate the table, add the allow method from the tutorial to your before filter in Users controller and add new users who are linked to the appropriate groups. Remember: We are focused on role based authentication so you should have assigned group as parent to user.
2) Truncate the table and manually add the groups required (should only be a handful)

Once you have fixed your ARO table you should rerun the initDB method in your Users controller to recreate the join table (aros_acos). I'm not sure why this join table is named in such a way as to break Cake conventions but truncating it and rerunning your initDB method (see the tutorial) is the way to fix permissions.

What happens if you get a node error? No problem really - resync your ACO table with AclExtras plugin (see tutorial). When will this occur? If you add a new controller, or a new method to a controller. This is why I use the ACL shell (linked above) to export the ACO tree (created with AclExtra's plugin). It allows me to quickly check what nodes exist.

What do the tables do?

  1. 'acos' => objects that can be requested by ARO
  2. 'aros' => requester objects that require access to protected ACO
  3. aros_acos => join table linking the permissions
In the tutorial linked above the initDB method sets up the 'aros_acos' join table.

Any questions?  Please comment on the post and I will answer.

Comments

Popular posts from this blog

Separating business logic from persistence layer in Laravel

There are several reasons to separate business logic from your persistence layer.  Perhaps the biggest advantage is that the parts of your application which are unique are not coupled to how data are persisted.  This makes the code easier to port and maintain. I'm going to use Doctrine to replace the Eloquent ORM in Laravel.  A thorough comparison of the patterns is available  here . By using Doctrine I am also hoping to mitigate the risk of a major version upgrade on the underlying framework.  It can be expected for the ORM to change between major versions of a framework and upgrading to a new release can be quite costly. Another advantage to this approach is to limit the access that objects have to the database.  Unless a developer is aware of the business rules in place on an Eloquent model there is a chance they will mistakenly ignore them by calling the ActiveRecord save method directly. I'm not implementing the repository pattern in all its glory in this demo.  

Fixing puppet "Exiting; no certificate found and waitforcert is disabled" error

While debugging and setting up Puppet I am still running the agent and master from CLI in --no-daemonize mode.  I kept getting an error on my agent - ""Exiting; no certificate found and waitforcert is disabled". The fix was quite simple and a little embarrassing.  Firstly I forgot to run my puppet master with root privileges which meant that it was unable to write incoming certificate requests to disk.  That's the embarrassing part and after I looked at my shell prompt and noticed this issue fixing it was quite simple. Firstly I got the puppet ssl path by running the command   puppet agent --configprint ssldir Then I removed that directory so that my agent no longer had any certificates or requests. On my master side I cleaned the old certificate by running  puppet cert clean --all  (this would remove all my agent certificates but for now I have just the one so its quicker than tagging it). I started my agent up with the command  puppet agent --test   whi

Redirecting non-www urls to www and http to https in Nginx web server

Image: Pixabay Although I'm currently playing with Elixir and its HTTP servers like Cowboy at the moment Nginx is still my go-to server for production PHP. If you haven't already swapped your web-server from Apache then you really should consider installing Nginx on a test server and running some stress tests on it.  I wrote about stress testing in my book on scaling PHP . Redirecting non-www traffic to www in nginx is best accomplished by using the "return" verb.  You could use a rewrite but the Nginx manual suggests that a return is better in the section on " Taxing Rewrites ". Server blocks are cheap in Nginx and I find it's simplest to have two redirects for the person who arrives on the non-secure non-canonical form of my link.  I wouldn't expect many people to reach this link because obviously every link that I create will be properly formatted so being redirected twice will only affect a small minority of people. Anyway, here's