←CakePHP ACL Tutorial: Initial Setup| CakePHP ACL Tutorial: Introduction→
View full index of ACL Tutorial Articles
The ACL Component is designed with a lot of flexibility in how it can be used, so it can be used with many different user management systems.
The way in which the ACL is configured will most likely be directed by whatever user management system you have in place. Two different websites could both use the ACL Component, but have different looking ACL database tables, because of differences in user management systems used.
The Authentication Component in particular requires one of two somwhat incompatible configurations of the data within the ACL Component. Each configuration also has some consequences on how the ACL Component’s functions are called. Therefore, it is important to figure out what direction you want to go before setting up your ACL Component, because change at a later stage will require a fair amount of reworking of your site’s programming logic.
If Authentication is set to work under ‘actions’ mode, then the ACL’s ACO hierarchy will be required to have a tree structure like this one:
Site
--Articles
----edit // controls access to /articles/edit
----delete // controls access to /articles/delete
----index // etc...
----view
--Comments
----edit
----delete
----index
----view
In addition, in the aros_acos table, for each row that corresponds to a particular permission, ALL FOUR of the action columns (_create, _read, _update, _delete) needs to be set to 1, in order for permission to be granted. If any one is set to ‘0’ or ‘-1’ no permission will be granted to the entire node.
To set this up, the following syntax must be used any time the ACL Component’s allow() command is used:
Acl->allow('bettycrocker', 'Articles/index', * );
Here, the ‘*’ sends the message that ALL four action columns in the aros_acos table should be set to a value of ‘1’.
In actions mode, the key point to remember is that each action needs to correspond to an ACO node whose alias is the same name as the action. And, this node needs to belong to a parent node whose name corresponds to the CamelCased name of the controller.
Also, note that this means that MANY of your ACO nodes will have identical ‘alias’ values. You are going to have many nodes with the alias ‘edit’, who can only be differentiated by looking at their parent_id values.
If Authentication is set to work under ‘crud’ mode, then the ACL’s ACO hierarchy will need to have the following tree structure:
Site
--Articles
--Comments
In this mode, the full functionality of the aros_acos table will be utilized, so that access will be granted to an action only if the column for that action is set to a value of ‘1’.
To set this up, the following syntax must be used any time the ACL Component’s allow() command is used:
Acl->allow('bettycrocker', 'Articles', 'read' );
Here ‘read’ is used. In this case, the command would grant permission to:
http://www.website.com/articles/index
// AND
http://www.website.com/articles/view
Under ‘crud’ mode, both ‘index’ and ‘view’ are considered a ‘read’ action, so access to both pages is granted with a single grant to the ‘read’ action.
The primary difference from actions mode will be a dramatically reduced number of ACO nodes, most of which are going to have uniquely named aliases.
The Authentication Component typically maintains a user table to store usernames and passwords. It is necessary to maintain a synchronization between the system’s user tables and the ACL’s aros table.
The ACL Behavior is a very useful tool to help maintain this synchronization.
Whether you use the built-in behavior or not, you must make sure that the following synchronization is maintained:
Tuesday April 15, 2008
The alias value in the ACO table does not need to be unique. Identical values are distinguished by having differing ‘parent_id’ values. By using the forward slash syntax ‘Articles/index’ you are telling the ACL Component to look for the node with an alias ‘index’ whose parent_id corresponds to the node with the alias ‘Articles’. This is the syntax used by the built-in Auth Component. Under ‘actions’ mode, you will likely find yourself with many ACO nodes with the alias ‘edit’ and ‘add’.
←CakePHP ACL Tutorial: Initial Setup| CakePHP ACL Tutorial: Introduction→
I'm Aran Johnson and I make websites.
I primarily use: PHP, MySQL, SubVersion, CakePHP, TextPattern, Cream Text Editor, and Addi Turbo Needles
Guitar Hero World Tour Microphone Compatibility
A Call For a New Standard Web Design Practice
Dollar and a half cardigan ... finished!
CakePHP ACL and Auth: Sample Website
CakePHP ACL and Auth Tutorial: Database Setup
CakePHP ACL Tutorial: Introduction
CakePHP ACL Tutorial: Usage With Auth Component
CakePHP ACL Tutorial: Initial Setup
CakePHP ACL Tutorial: Auth Component Example
CakePHP ACL Tutorial: How To Check Access
Cake PHP ACL Tutorial: The Database Tables
Just to clarify with regard to Authentication in `actions` mode… The code example as shown below:
Acl->allow(‘bettycrocker’, ‘Articles/index’, * );
And the paragraph description:
“In actions mode, the key point to remember is that each action needs to correspond to an ACO node whose alias is the same name as the action. And, this node needs to belong to a parent node whose name corresponds to the CamelCased name of the controller.”
...these seem to not completely match. From the other articles I’ve read, the an alias should have a unique name so that it doesn’t conflict with other actions of other controllers, but here you say that the ACO alias is not the same name as just the action. I’d just like to clarify that you’re showing an example project-specific (personal) convention, or if this is a convention within Cake now. As your set of introductions have become the defacto standard for reference in the mailing list and IRC, I just want to be certain that I understand this correctly. :) Thanks for all the work on this! I’ll definitely be reading over the acl.test.php file as well!
— Brendon Kozlowski May 14, 02:25 PM #