Extending ACL to per field

10 10 2007

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.

Advertisements

Actions

Information

7 responses

10 11 2007
Jimbo

Hi Mr Lemonbaker,

I’m really interested in implementing “Actions per Rols” into my Cakephp application having got the basic Acl/Auth system working. You gave 2 options. 1) To create separate actions and views & 2) Create only separate views using $this->render.

Please could you explain more fully both options, including the routing you would do for option 1 (I know you said you were lazy but I am amateur as well as being lazy!).

I’m sure other bakers will be pleased to have a bit more information here as ACL is a tricky bastard 😉

Many thanks,

Jimbo

7 04 2008
Forex Rates Today

* 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

I think these problems are still a big headache.

11 07 2008
Joe Beeson

There was a great couple articles by a very talented MySQL developer (Xaprb) that outlined a system to handle many things just like this. I’ve created a behavior to do just that, it’s still very rough around the edges but it works.

If you’re interested it can be found here.

9 08 2008
Patrice Lazareff

I had to implement a “per field” system some years ago, not with CakePHP then.

After reading your opinion, I think I would suggest an “in between” solution.

The Cake ACL system, while great, is far from being light on MySQL, and the acos table in particular needs to have some indexes properly set in order to slighltly improve things.

This to say that for a per field level, I would rather create a specific model, say fields, for which the table would be

user_id
model
field

and implement its features in the app_controller/model.

I admit I haven’t thoroughly thought about it, but I am pretty sure this would make a large app (with lots of aco’s) more responsive than the all-acl version.

FWIW, p @ T

15 08 2008
Adam

Hi Geoff,

Are you still around? How can I get in contact with you? I couldn’t find an email address on this site.

Cheers,
Adam

10 03 2010
Kingfisher Flight Tickets

Good Article … But Problem are still a big issue.

13 05 2010
kingfisher

yae, why people pick tail and run behind you, no one is having an answere to it, anyways, the per field system should be there though in order to avoid it at all, thanks king

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: