Best way to add new user with different levels php

Question

I have created an application in PHP that has users and the users have different levels, lets just say 1, 2, 3, 4. When the user logs in it sets a session with their level number in it. The application shows different pages depending on user level like so:

if($role_level > 3)
{
    //Show something
}

Now I want to create an add user section where the user can add a new user and define them a role probably from a drop down (html select) box. But they can only define a role that is lower than their own. I'm thinking something like this:

<select>
    ("SELECT * FROM `roles` WHERE `roles_level` < $role_level)
    loop results into <options></options>
</select>

Any comments on this? Better ways to go about it? Will the above be affective?

Answer 1

Your idea seem viable but it's not very flexible because it allows for a single direct hierarchy between roles. What if you need branching roles? For example, you may now have "users", "publishers", "reviewers" and "admins" as your current 1, 2, 3, and 4.

users can only read articles, publishers can also write and edit their articles, reviewers can also edit other publishers' articles and admin can also do admin stuff.

what if you want a moderator role? A moderator can edit articles, of anybody, but not write new articles. How would you implement that? You can't with your current model.

I suggest you to define a "roles" table, an "actions" table, and an N-M relationship table between them:

Roles:

• 1, user
• 2, publisher
• 3, reviewer
• 4, admin
• 5, article_moderator

Actions:

• 1, read_post
• 2, write_post
• 3, edit_own_post
• 4, edit_others_post
• 5, administrative_tools

Roles_Actions:

• 1,1
• 2,1
• 2,2
• 2,3
• 3,1
• 3,2
• 3,3
• 3,4
• 4,1
• 4,2
• 4,3
• 4,4
• 4,5
• 5,1
• 5,4 (note that moderators (5) can't write_own_post or even edit_own_post but only edit_others_post)

sure, this is more complex, but its more flexible for the future

I suggest you to read this answer too: LINK by @Vyktor which explains the ACL concept, useful for larger projects

Answer 2

I think STT LCU already provided a great answer, but for studying purposes (yes, this is just an extension) I'd like to add example how this can (and is done) in production environments, my favorite example - Zend Framework's Access Control Lists.

They specify three separate items/objects/not sure how to call them:

• Resource - what are you referring to, this can be large items such as Forums, News, Articles... or atomic items such as Forums_<forum_id>_others_posts_title. This should depend on how many users are you expecting and how complex the structure is. If you will have just 10 users and one admin, you'll be fine with one resource for whole site. On the another hand... Imagine you're google, have thousands of applications under your control and you want to propose unified and centralized ACL control... Many, many, many resources.
• Role - this should be self explanatory, but examples: Banned, Visitor, User, ForumModerator, ArticlesModerator, SiteAdministrator. In optimal framework (such as mentioned Zend) you can build hierarchy and inherit access among roles.
• Access Control - Visitor can list list articles, but cannot read them... This is again thing that should be intuitive, but here's a little controversy:
  • Using hierarchy - let's say you specify hierarchy like this none < list < read < write < create < edit < delete and having one automatically grands you all to the left, for example write automatically grants you read and list. This is nice, intuitive... But here's one example when this methodology is useless: Black box, where you want users to post items, but not to read them.
  • Using flags - **x chmod style* where access is determined from flag:
    • 1 - execute/list content of directory
    • 2 - write
    • 4 - read
      Where you can use binary and to check access: access&WRITE, or use sql schema with large number of columns.

To sum up: there's large number of things you can do, I really do recommend to read about Zend's ACLs so you'll get feeling how the API may look, maybe you'll realize some possible drawbacks you wouldn't think of on your own.