views:

121

answers:

3

That's kinda vague so here's the meaty stuff:

I have seen authentication systems that do one of the following

  1. have a separate role table for each roles, and a separate permissions table, all users in one table
  2. have a separate table for administrators

there's a lot that I have missed, I know. But what I'm trying to really ask is:

How should I design my database in a website that I have a lot of kinds of users and each with different access?

How will I make it so that my script is flexible enough if I decide to add another type of user with another type of permissions?

I currently have a User class and am planning to make my Administrator class which extends that User class. Or is that a bit of an overkill when I can have them all in a single class and just assign necessary permissions?

+1  A: 

you can have tables -

user (user_id, name ...)
permission (perm_id, name, desc)
role (role_id, title)
user_role (user_id, role_id)
user_permission (user_id, perm_id)
role_permission (role_id, perm_id)

This way you can have as many roles in the system as you require, and you have both role level permissions, user level permissions.

Wbdvlpr
+2  A: 

you can add an additional level of abstraction. basically you add a table in your database to manage user groups, and assign group permissions to those groups. different users can have multiple groups.

this way you can quickly change permissions to a predefined set of rules, without needing to change every user separately. you can also change the permissions for a group of users at once

knittl
A: 

I think you need to think about several concepts here. The first would be an access control list (ACL) and then second would be authentication.

In an ACL, you define resources, which are objects that you want to restrict access to and roles, which are objects that may request access to a resource.

The way I implement my ACL, is using Zend_Acl. I have a table called user_roles

user_roles('user_role_id', 'name', 'permissions', 'parent_role_id')`

I also have a table called user_role_maps that maps a user's ID to a user role ID. (You could just have this as a column on the user table, but that just depends on how you feel about normalisation ;-) .) I can then construct my Zend_Acl object from this table and then, when a user is authenticated, I can determine which resources they have permission to and what actions they can perform on a resource. (A resource implements Zend_Acl_Resource_Interface so it is identifiable by Zend_Acl as a resource.

As for authentication, this is a simpler concept (in my opinion), you've probably already figured out some form of token matching authentication system yourself. The crucial aspect is using the authenticated user's ID to determine their role. The Zend Framework also provides a package for this in Zend_Auth.

I've used a lot of Zend Framework recommendations here, the reason for this is that their packages have very few dependencies on other packages, making it quite simple to plug components in. I'm sure other frameworks provide ACL packages that you could use, or roll out your own if you have the time and understanding.

Good Luck.

Kieran Hall