Cake PHP ACL Tutorial: The Database Tables

View full index of ACL Tutorial Articles

Understanding the way the ACL’s database tables are structured will be very beneficial to understanding how
the component works.

The component relies on 3 tables of data:

• aros (Access Request Objects): In most cases, this table contains names of users and usergroups;
• acos (Access Control Objects): These are typically names of controllers and sometimes names of controller actions;

• aros_acos (Permissions): This is a table in which each row contains an id of an ARO, an id of an ACO and for each type of access action — Create, Read, Update and Delete — a value is assigned that grants or restricts access to that action.

The aros Table

| id | parent_id | model | foreign_key |   alias  | lft | rght |
|  1 |   null    | Group |      1      | guests   |  1  |  10  |
|  2 |    1      | User  |      1      | alien    |  2  |   3  |
|  3 |    1      | Group |      2      | crew     |  4  |   9  |
|  4 |    2      | User  |      1      | ripley   |  5  |   6  |
|  5 |    2      | Group |      1      | officers |  7  |   8  |

In this ‘aros’ table, any permission granted to guests will be inherited by all others below it, because the lft and rght values of every other row fall between the numbers 1 and 10. Meanwhile, any permission granted to officers will only be owned by the officers, since no row has officers as it’s parent nor has lft or rght values that fall between 7 and 8.

In addition, ripley’s values (5,6) and officers values (7,8) are both within the range of crew’s values (4-9), so this indicates that both ripley and officer inherit values from crew.

But, since the range of ripley’s values do not intersect with the range of officers’ values (5-6 vs. 7-8) this means that permissions can be assigned to ripley that will NOT be inherited by officers.

The acos Table (under Authentication’s ‘crud’ mode)

| id | parent_id | model | foreign_key |    alias    | lft | rght |
|  1 |   null    |       |             | intranet    |  1  |   6  |
|  2 |    1      |       |             | crewmembers |  2  |   3  |
|  3 |    1      |       |             | specimens   |  4  |   5  |

The same number system operates on the ‘acos’ table.

In this example, crewmembers and specimens are both descendants of intranet, but neither is a parent or child of the other. This means that if we grant ‘read’ permission to intranet to a user, the user will have ‘read’ permissions on ALL AROs whose lft and rght values fall within the range of 1-6. Giving ‘delete’ permission to crewmembers or specimens in contrast will not result in any sort of inheritance of that ‘delete’ permission.

As new ACO rows are added, the lft and rght values will change accordingly. Thus, if an ARO is granted permission to intranet, this ARO will maintain access to any future ACO that is added as a child of intranet.

The aros_acos Table (under Authentication’s ‘crud’ mode)

| id | aro_id | aco_id | _create | _read | _update | _delete |
|  1 |    5   |    1   |     1   |    1  |    1    |    1    |
|  2 |    2   |    2   |     0   |    1  |    0    |    1    |
|  3 |    4   |    3   |    -1   |    0  |   -1    |   -1    |
|  4 |    3   |    3   |     1   |    1  |    1    |    1    |

In this example, the ARO with id 5, officers has create, read, update and delete permissions for the ACO with id 1, which is intranet. This means that officers will continue to have full access to any new ACO added to the acos table that is added as a child of intranet.

The ARO with id 2 alien only is given access to ACO with id 2, crewmembers. In this case, alien can only ‘read’ and ‘delete’ crewmembers.

The ARO crew is given full permissions for the ACO, specimens in row 4 of ‘aros_acos’. Since ripley is a child of the crew ARO, then this would suggest that ripley would inherit full permissions to the specimens ACO.

Unfortunately, ripley is explicitly denied the permission to create, update and delete specimens with the values ‘-1’. This means, that she loses the permissions she inherited. Her ‘read’ permission is set at ‘0’, though, which means she does inherit the ‘read’ permission granted to crew.

Getting Deeper

The model definitions for these tables are grouped together into one file in the core: db_acl.php.

For the sake of understanding and troubleshooting the programming logic of the ACL Component, it is important to understand that the Aco and Aro models both inherit a lot of functionality from the Tree Behavior. Thus, a deeper understanding of that behavior will directly lead to a better understanding of the way the ACL Component functions.

Sunday April 13, 2008