access control from a different point of view

[eluser]jaume[/eluser]
Hi all! :coolsmile:

I've been reading and searching for some time this great forum pages and solved most of my questions... But there is one topic that keeps me from using CI in clients apps...

I've made webs for small towns where every association in it has it's own "miniweb" in it, and every association may have more than one user with different access levels to different parts of their minisite... So I need validation on a per page basis.

Until now I've used a table where every row is a user and every column is a section of the site, having different levels of access.

Let me use a small example:

user.....homepage.....news.....faq.....calendar
john..............3.................3...........3.............3
pete..............3.................1...........1.............2
alex..............1.................2...........2.............2

So, as you can see, they don't belong all to a level alone, but to different access levels depending on the section.

The apps I've found let me say jonh has level 3 for everything, alex has level 2, etc... But not use levels for single sections.

Also, we are talking of more than 50 users and 30 sections, so a config file would not be a good option...

So, am I the only one using this approach? It makes it really easy to control access checking the access level on entering every back-end page like "if level is 3 for this page show delete button" or "if level is 2 validation of article is pending for this author".

- Any app working like that that I missed?
- Or suggestion to load a table from a DB into a matrix and keep it as a session var to check in every page of the back-end?

Thanks in advance!

Jaume.

[eluser]Rick Jolly[/eluser]
I'm thinking that your authorization method isn't very scalable.

One reason is that you are maintaining access permissions on an individual user level. Even if john and pete have similar permissions, you have to write each individually. You could use roles/groups instead. That way john and pete could belong to the same role, but if pete has a few extra permissions, he could also belong to an additional role.

Another problem that I see is use of permission levels as opposed to a boolean allow/deny. The permission levels are ambiguous. They don't have any meaning on their own. For example, in your code you define what "3" means for a particular "resource" (ie. button) on a particular page. What does "3" mean on a different page? Just looking at the number "3" for homepage doesn't tell me anything. An alternative would be to do something like this:
.........homepage/index...homepage/edit
admin....allow..............allow
guest....allow..............deny

etc., etc.

That would take some time to set up, but it is easy to use (ie. isAllowed('admin', 'homepage/edit'), explicit, and scalable. For something more powerful you might want to look at the zend acl. It allows resource and role inheritance which makes setting up an acl very quick - a lot less typing and fine grain control.

Sorry for not answering your questions though.

[eluser]jaume[/eluser]
Hi Rick! :coolsmile:

The role levels are numbered but their labels in the form are writer, editor and admin so it makes more sense and previous sentences turn into "if is admin (level 3) show delete button" and "if is writer validation of article is pending (editor task)" you have a long list of permissions, but the default values save you a lot of work as all users have permission (for example) to change their own password but are not allowed to enter 90% of the sections to edit or create content as they belong only to one or two clubs (or associations) and you only have to change permissions for this one or two areas.

Also being numbers allow to say "editors or higher level can do x...." like "if level >1 then x allowed".

Anyway, I'll take a look at Zend's ACL.

Thanks!