Page 1 of 2
Is this a good idea?
Posted: Fri Jul 14, 2006 4:02 pm
by Luke
For a user management system: to include a field in the database with a creator_id so that the user who created you can not be deleted by you... or is there a better way to acheive this... I am trying to avoid the user_level approach... unless there is a clean and easy way to go about it.... suggestions?
Posted: Fri Jul 14, 2006 4:07 pm
by Luke
Or wait... even better.. how about a setup like this:
group_privs table with group privileges (user object grabs privileges from this first)
users_privs table with individual user privileges (user overwrites their group privileges with any of these that are present)
individual module privileges with module-specific privileges (this is me thinking outloud (on the screen))
Posted: Fri Jul 14, 2006 4:12 pm
by timvw
Do a websearch for 'rbac / role based access control'... You'll find some interesting approaches

Posted: Fri Jul 14, 2006 4:31 pm
by Luke
thank you...
EDIT:
http://en.wikipedia.org/wiki/RBAC - seems complicated... more complicated than necessary for my app. Is this just a bad explanation perhaps?
Posted: Fri Jul 14, 2006 4:43 pm
by Ward
I think you would be better off assigning groups and permissions. Users with 'delete user' permission would not be allowed to delete groups higher than them.
For example:
SuperAdministrators
-- Administrators
----PowerUsers
------Users
Someone in the 'Administrators' group wouldnt be able to delete someone from the 'SuperAdministrators' group.
Posted: Fri Jul 14, 2006 4:44 pm
by Luke
that is what I am trying to avoid... I don't like having "levels"
EDIT: well... I don't mind having levels as long as they can be overridden.
Posted: Fri Jul 14, 2006 7:05 pm
by Chris Corbyn
The Ninja Space Goat wrote:
that is what I am trying to avoid... I don't like having "levels"
EDIT: well... I don't mind having levels as long as they can be overridden.
Have you considered assiging permissions as "bits" and looking which "bits" are set for a user? This gives you a lot of flexibility to swap and change a user's permissions though it's not nearly as convenient as RBAC. From what I've just read RBAC is used lots, whereby you assign the permissions to a "group" and then assign users to those groups.
By setting permissions for each user you'd cut out that "level" issue I think you're talking about, if I understand you correctly.
Example:
Code:
Code: Select all
Bit Token
-----------------------------
1 Create Users
2 Delete Users
4 Edit Posts
8 Post News
Then joebloggs needs to be able to edit posts and post news so we give him those bits which makes 4 + 8 = 12.
Now we enter a part of the system where only users with the "Delete Users" bit can go so we check joebloggs' permissions:
Code:
Code: Select all
if ($permission & 2) //If the "2" bit is set
{
//We can go in here
}
Posted: Fri Jul 14, 2006 7:37 pm
by Luke
hmm... interesting. Definately something to consider. Thanks.
Now that I really look at it, RBAC... may be what I am looking for
The reason I don't want to have "User levels" is because there are SO MANY privileges... there will be global privileges (create users, change control panel settings), user-specific privileges (change profile), module specific privileges (add news article, upload photos to file bin), and user-module specific privileges (delete (your) news article).
A User-level system just wouldn't do it.
Posted: Fri Jul 14, 2006 8:14 pm
by Nathaniel
Oh my goodness, d11, that is slick.
Posted: Fri Jul 14, 2006 10:18 pm
by Jenk
If you've ever administered users/groups on Active Directory, that's an example of RBAC.
Posted: Sat Jul 15, 2006 12:56 am
by RobertGonzalez
The Ninja Space Goat wrote:hmm... interesting. Definately something to consider. Thanks.
Now that I really look at it, RBAC... may be what I am looking for
The reason I don't want to have "User levels" is because there are SO MANY privileges... there will be global privileges (create users, change control panel settings), user-specific privileges (change profile), module specific privileges (add news article, upload photos to file bin), and user-module specific privileges (delete (your) news article).
A User-level system just wouldn't do it.
I set up a system like this for a tool at work. I used two field and level ids in each. The first field was the panel field (Global admin, site admin, sales admin, finance admin, enginerring admin) and the second was modul specific. This allowed me to tailor the admin panel to each user, and, within that panel, allowed me to set which modules were viewable and usable. The nice thing is that as a global admin, I could change this by simply selecting a different user level/module level in their profile. Just a thought.
Posted: Sat Jul 15, 2006 2:30 am
by timvw
Eg:
http://www.tonymarston.co.uk/php-mysql/ ... ntrol.html is an article that describes a couple of possible solutions...
Posted: Sat Jul 15, 2006 11:10 am
by Christopher
On small sites I do the same thing -- but the long way spelling out groups and then exploding them. It is a little more processing, but becaue it is human readable I don't need an admin page to adminster them or a cheat sheet to lookup the values.
Code: Select all
String Token
-----------------------------
'create' Create Users
'delete' Delete Users
'edit' Edit Posts
'post' Post News
So the data stored looks like 'delete|edit|post'.
Code: Select all
$permission = explode('|', $user['permissions']);
if (in_array('delete', $permission))
{
//We can go in here
}
I usually cache the permissions in the session so its only the in_array() call.
Posted: Sat Jul 15, 2006 11:32 am
by Chris Corbyn
arborint wrote:On small sites I do the same thing -- but the long way spelling out groups and then exploding them. It is a little more processing, but becaue it is human readable I don't need an admin page to adminster them or a cheat sheet to lookup the values.
I define constants to represent those values (though they could be stored as properties too) which makes it more readable but at the end of the day a simple method would do:
Code: Select all
if ($this->user->hasPrivilege(EDIT_POSTS))
{
//Dumty dumty dum...
}
else //kick user away
Code: Select all
public function hasPrivilege($bit)
{
if ($this->assignedBits & $bit) return TRUE;
}
Posted: Sat Jul 15, 2006 2:04 pm
by Christopher
Yeah, but by the time you add a bunch of define statements the performance difference between the & and array check is gone. I have just found that the sloppy string method is handy -- especially with clients that keep changing things. If they need a new group I just add it to those couple users with phpMyAdmin and then add the group names to the pages that are now allowd to access. I find I make less errors when the access value is 'create|edit|post' than 48.