views:

97

answers:

2

I've been reading up on (Role-Based) Access Control Lists for an upcoming project and am having some troubles figuring out how it will work for me.

In the examples I've seen, they always talk about allowing and denying access to the particular actions of a controller/model. For example: the group "Visitors" can read posts, "Members" can read and edit, and "Admins" have create, read, update, delete.

These things seem to be a bit too global for me. In my own situation (adjusting it for this example), there will be a large number of groups, each of which can only edit posts which belong to a certain category (or some other criteria).

The only way that I can think to make it work for me is to create a new ACO for posts for each category:

posts_cat:1
posts_cat:2
posts_cat:3

And then give access to each of those individually (which could be a royal PITA for administrators who need access to all)

How does the ACL pattern cover situations like this? Are there better methods?

I will eventually be implementing this in PHP, using Cake, so examples using PHP are welcomed, but not required!

A: 

There's always something better than an ACL; whether or not you'll be allowed to implement it is another story altogether. I've always found this presentation amusing:

http://blog.cusec.net/2009/01/05/zed-shaw-the-acl-is-dead-cusec-2008/

Azeem.Butt
Thanks for the link! I'll have to check it out later tonight - stupid corporate firewall blocking vimeo...
nickf
A: 

One option are rules like these:

allow('your_role', 'edit_post', 'draft'); allow('your_role', 'edit_post', 'category1');

Or you could build an attribute based access control (which can be role based). That is allowing roles to do an action on an object (in the wider sense) based on attributes.

koen