Extending ACL to per field

In some recent comments I was asked how I would expand ACL to incorporate rights at a per field level. I can see how this would be useful, although in my opinion it would become too unweidly for the admin to assign rights. It would be easier for the administrators to have multiple actions/views with the appropriate fields in them. I will outline both methods and there relative merits.

ACL per Field

The complex and ugly part of this method is the administration interface. The actual creation of ACO’s and access control can be done quite elgantly in Cake using a behaviour. All this requires is that in Model::afterSave() each fields ACO is created. Similarly for access control, in Model::afterFind() loop over each field, check the current users permissions and then unset the fields that are restricted.

Advantages

• This method allows very fine grained control. Each record will have it’s fields able to be restricted independantly of other records of the same model
• When access rules change, views and actions don’t

Disadvantages

• Greater ACL overhead
• ACO table grows much faster with respect to number of model records.
• Views bedome more complex (logic to test which fields are available)
• Unweidly managment interface

Actions per Rols

This method creates seperate actions/views based on the current users role, similar to the way admin_ works. There are two options with this method. Seperate actions and views per role, or seperate views only through $this->render($role.’_’.$action). Personally I would use the seperate views only as this does not require creating Route rules – yes I am lazy

Advantages

• Simplified logic. One extra line per action and no extra ACL overhead.
• Simplified management
• Field control at the Model level, not record level

Disadvantages

• Field access must be determined at design time
• When rights change, so do views

Conclusion

While the first method provide far greater control over field rights at a record level, I feel that it is overkill and not worth the extra ACL and database overhead. In my experience, per user per record per field control has never been required. The simplified view switch method provides more than enough control for the majority of applications.

I find that access control is usually defined before implementation, and rarely changes while in production. This makes the trade of simplified code and management with the need to update files in the event of rights changes worth while.