I am learning the ACL feature of cakephp. I have gone though cakephp docs. For learning more, I have checked the code/db of some ACL plugins like croogo and alaxos ACL plugin. I can see that in aros_acos table, there are columns like _create, _read, _update and _delete. From those examples (croogo/alaxos), for an action, for example:- add (under users controller), I can see the value as 1 1 1 1 in _create, _read, _update and _delete columns. As the name indicates add should only be mapped to _create (1 0 0 0), right ? Also, in this scenario do we need 4 columns ?
Im confused with the action mode with the CRUD mode. In my application, there are some features like approve, reject etc other than CRUD. Do I need to add columns for these actions ? Or mapactions will be suitable for this (in that case, do I need to map all actions in the controller) ? Also, in my app I need to give the owner edit and owner delete permissions . How to do all these with the Cakephp ACL in a better way ?
It depends on what you want to do with Acl. What you have looked at in Croogo or Alaxos Acl plugin (my plugin by the way) is the use of Acl to allow/deny access to some actions.
This is achieved by the use of the AuthComponent and AclComponent together. When doing this, if you look at the Cake code, the permission check is done in the
DbAclclass in the following method:which takes potentially three arguments.
The call to this function is done by the
ActionsAuthorizeclass in theauthorize()function at the following line:which is obviously a call without the third argument.
So basically what is this third argument ? It is the way to take care of the _xxx fields of the aros_acos datatable. So all together this means that the Auth+Acl components do not use these _xxx fields to check permissions.
Well actually they are used, but differently: when the third argument is not used, all fields set to
1means allowed, and if one or more fields are set to-1, it means denied.Personally for the Alaxos Acl plugin, I choosed to set all these fields to
-1for a deny, just for more clarity.Regarding your application, if its ‘features’ are mapped to actions, you could probably just forget these _xxx fields and use the core Auth+Acl mechanism.
About your last question (owner edit and delete), it is a frequently asked question with Cake ACL.
The answer is most of the time that it is simpler to compare the Object.user_id and the logged user id to decide if a user can edit/delete a record. Cake ACL does not support record’s owners out of the box.