ACL in simple terms

[eluser]kr1pt[/eluser]
Hello. I speak English pretty well, but I can't understand the term 'role'. How does it work? Is role a user group?

Let's say that I have a user called Derp, now I assign Derp user_group = 'user'. CI gets all the permissions where allowed_groups = 'user, other group, new group' can have. Is this good approach? Or is this the better approach:

group_permissions [group_id, permission_key]
permissions [key, description]

Derp's group ID is 1. Now if $this->get_permission('permission_key') exists in group_permissions, we allow him to view content.

If this ain't good, someone please explain me ACL in simple terms.

[eluser]PhilTem[/eluser]
A role is a group but it isn't a group, too.

From google (query "define role") we get

The function assumed or part played by a person or thing in a particular situation.

That's what you should keep in mind when you think of roles. Of course, in a simple setup you can say role == group, but if you want to have permissions defined more precise, you should use roles instead of groups as "thinking of".

I always think of roles like this:
A role is a set of permissions the users assigned are allowed to perform or a set of resources the users may access.

So to speak, I usually split up my ACL in three parts:
- Resources (what can be accessed)
- Roles (what we are trying to clarify, what it is)
- Permissions
- Users (but they don't really count for an ACL here)

So, you set up resources (something that may be access like 'admin.users.add') and add roles (something like 'Administrators', 'User managers', ...). Then you combine these resources with the roles and assign 'allow' or 'disallow' to them. Which leads you to the 'permissions'.
The last step is actually to assign roles to users (I'd say, you assign roles to users and not users to roles. If you assigned users to roles you'd actually have groups). That way the users get all the permissions granted to each role they own. Any permission not assigned is either given by the defined parent role or - if no permission can be found - denied by default.

That's the way I see and use an ACL for my projects. There are other approaches, but for me, this one works pretty freakin' awesome and is failsafe.

[eluser]kr1pt[/eluser]
Thanks a lot for clearification. For every user create permission for each resource, that's a lot of queries while proccessing/updating/adding permissions, huh..

...just last night I did the same you have, thats why I say there are so many queries.

[eluser]PhilTem[/eluser]
[quote author="kr1pt" date="1332507103"]Thanks a lot for clearification. For every user create permission for each resource, that's a lot of queries while proccessing/updating/adding permissions, huh.. [/quote]

I don't feel it's that much queries to run since you usually set up the roles and resources in advance. As soon as a user registers, you have on query to create a record within the users table and one within the table where you store information, which roles the user belongs to. So that's a maximum of two queries for basic user registration.

But you're right, it takes a lot of queries to configure the roles and permissions. Yet you only should need to do it once.
So, if your ACL-library is good, a user can be part of multiple roles which may have a different level of power. Like with phpBB the moderators and global moderators. Additionally, permissions should be inherited by default. Imagine a resource admin and admin.users. Role 'Admins' has access to resource 'admin' hence it should automatically have access to resource 'admin.users'. There's no need to store this relation within the database as long as checking for permission can work with this 'missing information' (mostly the ACL checks for 'admin.users'-permission, won't find it and checks for 'admin'-permission. So there should be a recursion for permission checking).