ACL Layouts

[eluser]drewbee[/eluser]
Hello all,

This is not intended to be yet another 'i need an auth system' for CI, as, well, I need more so an ACL then the auth. The auth is the easy part. lol.


Basically, the project I am working on is going to be completely driven by groups, and each user is assigned to a group. As each user further follows and uses the site, there is going to be a promotion system in place that gives a user even more permissions.

Users can be assigned to 1-n groups.

*basically what I am asking is to help me get my head around this. I don't need code examples but more so the thought & logic for this*


This can get very confusing, so what I am thinking in my head is this:

Groups: (user can be assigned 1-n group(s))

There will be two categories of groups, the first one being a page access control list
This first section of groups will dicatate who can access what pages (from a global standpoint; no denying from interior page workings);
Group 1) Page Access Control Groups
Ex.
- Admin
- Member

The second group is what will be following the 'promotion' system. There are a hole other set of rules following this one, so for now just assume that based on a time frame they are promoted (new user group promotion each week).
Ex.
- Guest
- Univerified New User
- New User
- Helper
- Assistant
- Leader
- Manager
- Master

Now, there will be resources, of which will be assigned to each group. All actions will be assumed to have a positive action (IE CAN DO XXXXX). Which means if the group does not have the resource, they will be denied that action.
(we'll base it around a forum permission system to give us something to work towards);
- POST_NEW_TOPIC
- EDIT_OWN_TOPIC
- EDIT_OTHERS_TOPIC
- DELETE_OTHERS_THREAD
- DELETE_OWN_THREAD

*Access based permissions
- PAGES::REGISTER
- PAGES::LOGIN
- PAGES::LOGOUT
- PAGES::ADMINISTRATION

Pretty basic right?

Each usergroup will then be assigned a resource...
Ex.
- Guest
PAGES::REGISTER
PAGES::LOGIN
- New User
PAGES::LOGOUT
POST_NEW_TOPIC
EDIT_OWN_TOPIC
- MANAGER
PAGES::LOGOUT
POST_NEW_TOPIC
EDIT_OWN_TOPIC
EDIT_OTHERS_TOPIC
DELETE_OTHERS_THREAD

Then, Each user assigned a group & Page Access Controller
Ex.
user_1 :: Guest / Guest
user_2 :: New User / Registered
user_3 :: Manager / Registered
admin :: Master / Administrator

I was initially thinking I wanted to keep this all in tables, but do you think running attempting to pull this on every page load is feasible?

it would be something along these lines in the controller. I was thinking of actually pulling the data backwords based on resources needed from that page, and working my way back to the usergroup of which the current user is apart of.

Ex. Forum Posting New Thread

Code:

// load_resources will take two arrays, the first being the Page access, the 2nd the
// page access. If the page access fails page load will be aborted immediatley.

// Resource checks (will set an array of allowed resources (ie if user has it). If
// User does not have it, the resource is excluded from the set array. So lets say the
// has POST_NEW_TOPIC but does not have USE_BBCODE, the following array will be provided
// $resources = array('POST_NEW_TOPIC');
$this->acl->load_resources(array('PAGE::POST_NEW_TOPIC'),array('POST_NEW_TOPIC', 'USE_BBCODE'));

// So now, we can create a function that does the in_array check for the resource
if ($this->acl->is_allowed('POST_NEW_TOPIC'))
{
    // all my jazz for form display, validation, and other stuff
    $this->load->view('post_topic');    
    // And you may ask why not error out at a page level. Well, remember the BBCODE?
    if ($this->acl->is_allowed('USE_BBCODE'))
    {
        // Add additional Validation stuff IE only do bbcode parsing here)
        // The bbcode 'display bar' so to speak as well will be controlled from
        // within the view
    }
}
else
{
    // Do not have sufficient privledges
}

Eh...

So I guess after all of that, does this seem like a reasonable setup? As well, how well do you think this will be handled in terms of database queries?

For my entire set up for queries, it will follow this path, and I believe it can be done in 1 query.

>> Get usergroups from user_id
join resources for each user group where resource id IN ('*passed resources*') during load_resources() call

I think I have gone and confused myself now, but at the same time believe I have a monster in the making going on here, but it is neccessary for my up and coming project. And no currently built solution will handle this... and with this I havn't even gotten into the inheritance bit...

Oh well, I am running out of characters so I would appreciate any advice that can be given or if the direction I am headed is pretty solid.

And just for reference, I am building a forum for this site as well too, however, it is definately not the core It is nothing more then a slight addon. lol. Anyways, sorry for the long drawn read...

Thanks!

[eluser]jrad[/eluser]
I'm also interested on the developments regarding this thread... I hope someone will have an idea about this.

[eluser]Daniel Walton[/eluser]
Why not keep all of the required settings or permissions on one group level rather than having different flavours? Only I see that adding confusion and unnecessary bloat to whatever code you come up with.

If any group can have any/all properties this will enable them to be mixed and matched very easily, such that you could create an "Editor" group with all necessary permissions to do whatever editors do, or for a more fine grained approach create the separate groups of permissions and permutations to give you different levels of "editors" with the Editors group merely tagging those assigned with a label.

The way it would work is simple. Say I want to assign a permission for a particular task I could either create a new permission group for just that, or include it in an existing permission group. Any member with that permission group will then inherit that permission level.

e.g.,

editors('edit_posts' => 1, 'create_posts' => 1)
guests('create_posts' => 1)

Here editors have 2 permissions, to edit and create where as guests only have permission to create. While this would be replicating the permission to create posts across two permission groups that is purely down to how i've chosen to implement the system. I could of course create permission groups like so:

edit_posts('edit_posts' => 1)
create_posts('create_posts' => 1)

Then assign those groups to each account individually.

Taking it further the system could allow for permission groups to be nested, so for the above example you might assign those 2 to another group called "editors".

[eluser]manilodisan[/eluser]
You can also use group inheritance to avoid writing a lot of unnecessary code. This way, a group can inherit the permissions from another. You don't have to add multiple groups per user and all that stuff.

Anyways, if you're looking for a powerful tool with built in ACL system, user groups and all that hard stuff you can visit my sig. It's a free tool built on top if CI which gives you the admin to start your projects.

[eluser]xwero[/eluser]
manilodisan the group inheritance may be a way to cut down code but it can be inflexible.

A guest has the permission to comment on the blog posts and contact the site admin via the public contact form. An editor inherits the permissions of the guest but has to contact the site admin using the logged in contact form. So the right of the public contact form has to be taken away. And if you go up the ladder it's possible the right gets available again.

If you use a group as a template to you can create all kinds of variants. But this is more frontend than backend code because i would store each right for each group instead of linking rights from higher groups to lower groups. Doing this also makes the query for a right less complex.

To get back on topic, instead of putting the acl checks in the controller i would put them in the view. In the controller i would put a function that connects the page you are displaying with the user rights and in the view you generate the form elements using helper functions similar to the form helper of CI but with the additional check for the right to see/do something with those form elements.

Edit : an alternative is to create views for the different (groups of) users from an all rights template so you only have to load the right view.

[eluser]Hannes Nevalainen[/eluser]
There is a library thats already uses an ACL. As far I can see it would fit your needs. I haven't used it myself (never been required to). If you don't want to use it you could always take a peak in their code =)

http://phpgacl.sourceforge.net/

//Happy Coding

[eluser]esra[/eluser]
[quote author="Hannes Nevalainen" date="1222133294"]There is a library thats already uses an ACL. As far I can see it would fit your needs. I haven't used it myself (never been required to). If you don't want to use it you could always take a peak in their code =)

http://phpgacl.sourceforge.net/

//Happy Coding[/quote]

Do a search for KhACL or Khaos ACL. It is based on phpGACL and is not dependent on ADODB. The AXO object handling is different, but you can use the phpGACL docs to understand the ARO and ACO objects. The differences in AXO handling is documented in the khACL thread.

[eluser]manilodisan[/eluser]
phpGACL is very big and advanced. It might confuse you. Why not study zend's ACL lib and try to adapt it somehow?