An idea for improving CakePHP’s ACL system

Published on and tagged with acl  cakephp  ideas  zend

Recently, I stumbled upon an article about ACL in the Zend framework, written by Jani Hartikainen. While reading it, I realized that probably many people struggle with CakePHP’s ACL because of the naming.

The main classes of CakePHP’s ACL implementation are named ACO and ARO, which are acronyms for the technical terms “access control object” and “access request object”. An access control object is something that gets accessed, whereas an access request object is something that wants to access an access control object.

As those acronyms are probably not that familiar to most (I heard them for the first time with the introduction of the ACL feature), you always have to perform translations when you read/hear “ACO” or “ARO”:

ACO => Access Control Object => term you are familiar with
ARO => Access Request Object => term you are familiar with

After a while you (resp. your brain) will make those translations automatically. However, at the beginning, when you try to grasp CakePHP’s ACL implementation, those translation automatisms are not there yet, which makes the understanding more difficult…

Now compare this with the names used in the Zend framework: Zend_Acl_Resource (= ACO) and Zend_Acl_Role (= ARO). At least to me those names sound quite familiar. They are very similar to the terms I would use in a discussion about authorization. And because of this familiarity, the aforementioned translation process can be omitted.

And so I think it would also make sense for CakePHP to use terms like “resource” and “role” instead of ACO and ARO to make it easier for those who want to learn how the ACL feature works.

8 comments baked

  • Brendon Kozlowski

    Unless Cake decided to follow in Zend’s footsteps with a similar naming convention, I don’t think simply using “Resource” or “Role” would be sufficient, as those could quite easily end up being used in other models. I’d imagine it’s much less frequent (especially due to Cake’s naming conventions) for there to be ACO, ARO, and ARO_ACO tables.

    So…although I understand the reasoning for your thought, I think the small learning barrier is sufficient compared to the possibility for naming clashes.

  • Matthew Weier O'Phinney

    When coding Zend_Acl, we made the conscious decision not to use the terms ARO and ACO for the very reasons you describe: for most developers these are arcane terms that are not easily understood. “Role” and “Resource”, however, are simple to understand.

    As far as I’m concerned, this is part of the job of a framework: translating design patterns, algorithms, and abstract concepts into easily recognizable terms. The API will be used by developers day in and day out, and should be easily grasped.

  • Jeremy

    My way for remembering is pretty stupid, but I think

    ARO = Requestor
    ACO = Crap (as in, crap they’re requesting)

    not a great way :P but it works for me.

  • devsmt

    totally agree with you,
    +1 for your proposal

  • cakebaker

    @all: Thanks for your comments!

    @Brendon: Yes, using the names “Resource” and “Role” would probably lead to naming clashes. However, they could be easily avoided by using prefixes: “AclResource” and “AclRole”, for example.

    @Matthew: Yes, I fully agree with you. API usability is an important point to consider when designing an API, and in this regard you did a good job :)

    @Jeremy: *g*

  • sims

    I would like to say that ARO and ACO were easier and clearer for me as role is confused with RBAC which is supposedly different that ACL.

    That’s just me though. I was happy to see ARO and ACO and actually made CakePHP’s docs and implementation clearer for me than Zend. The only thing that stopped me from using Cake was it’s PHP4 support. :/

  • elantrix

    Isn’t the #1 rule in frameworks is to use encapsulation, this is no different for the ACL, where did cake_ go?

    Also, shouldn’t their be class(es) that provide the bare minimum to provide ACL features with an easy but highly configurable way to do more advanced functions.

  • cakebaker

    @sims, elantrix: Thanks for your comments!

© daniel hofstetter. Licensed under a Creative Commons License