Is this a good idea?
Moderator: General Moderators
Is this a good idea?
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?
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))
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))
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?
EDIT:
http://en.wikipedia.org/wiki/RBAC - seems complicated... more complicated than necessary for my app. Is this just a bad explanation perhaps?
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.
For example:
SuperAdministrators
-- Administrators
----PowerUsers
------Users
Someone in the 'Administrators' group wouldnt be able to delete someone from the 'SuperAdministrators' group.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
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:
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:
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 NewsNow 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
}
Last edited by Chris Corbyn on Sat Jul 15, 2006 9:27 am, edited 1 time in total.
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.
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.
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
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.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.
Eg: http://www.tonymarston.co.uk/php-mysql/ ... ntrol.html is an article that describes a couple of possible solutions...
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
So the data stored looks like 'delete|edit|post'.
I usually cache the permissions in the session so its only the in_array() call.
Code: Select all
String Token
-----------------------------
'create' Create Users
'delete' Delete Users
'edit' Edit Posts
'post' Post NewsCode: Select all
$permission = explode('|', $user['permissions']);
if (in_array('delete', $permission))
{
//We can go in here
}(#10850)
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
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: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.
Code: Select all
if ($this->user->hasPrivilege(EDIT_POSTS))
{
//Dumty dumty dum...
}
else //kick user awayCode: Select all
public function hasPrivilege($bit)
{
if ($this->assignedBits & $bit) return TRUE;
}- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
(#10850)