views:

74

answers:

3

Currently im just using something like:

in the DB Table:

access: home,register,login

and then in each page:

if(!Functions::has_rights('content'))
{
     Functions::noAccess();
}

is there more efficient way to do it, php & MySQL? i may want to gain access even to several parts a page, for example: user can read a page, but doesnt comment to it, and I dont want to build a separate system to each module.

Thanks in advanced, Tal.

+3  A: 

I believe what you are looking for is Access Control List where you model your problem into two things: objects and roles.

I do not want to impose it but using a framework is efficient I believe, the Zend Framework provides that, have a look here

You can also look for alternatives for "PHP ACL", in this SO question.

Bakkal
Zend_Acl is the only ZF I use in one of my sites and it's wonderful. Unless you want to go through the theory of ACLness to learn more about it (which I often like to do) I highly recommend dropping it in there.
Hans
+1  A: 

I built one using a "*NIX-type" permission system.

I have different type of permissions for a page (read, modify, delete, comment, vote) and I assign a bit to each of those.

So for instance I have

define ('USER_CANREAD', 1);
define ('USER_CANMODIFY', 2);
define ('USER_CANDELETE', 4);
define ('USER_CANINSERT', 8);
define ('USER_CANCOMMENT', 16);
define ('USER_CANVOTE', 32);

Then if the user can read, comment and vote the permission will be 1+16+32 = 49

To check for permissions I just do a bitwise AND with those values.

For instance user->permissions & USER_CANDELETE to check if the user can delete the page (obviously I have a canDelete function for that)

nico
A: 

If you are using some kind of routing it will make sense to make your ACL (Access Control List) depend on the routing that you have defined.

I usually run with a permissions table and a permissions_users table in a HABTM relationship. This way when the routing is matches, a permission can be looked up. If the user doesn't have the permission he is denied access. This can be improved with checking for the different types of methods GET, POST, PUT and DELETE.

This is because I like the opportunity to edit the permissions and settings from the web interface, and allow for non-it people to do the same (i.e. marketing people).

Here is the layout:

+-----------------------+
| permissions           |
+-----------------------+
| id | pattern | method |
+-----------------------+
| 1  |           | GET  | # => Will hit the root of your application
| 2  | users     | GET  | # => Will hit users/, usually listing the users
| 3  | users     | PUT  | # => Will hit anyone trying to insert a new user into the system.
| 4  | users/:id | GET  | # => Will hit anyone who tries to view a specific user
| 5  | users/:id | POST | # => Will hit anyone trying to update a user
+-----------------------+

+-------------------------+
| permissions_users       |
+-------------------------+
| user_id | permission_id |
+-------------------------+
| 1       | 1             | # => Will allow to view the root of the application
| 1       | 2             | # => Will allow to view the users list
+-------------------------+

So user 1 doesn't have any rights that could alter the records. And since the routing defines where the different request methods go, you cant simply POST to the /users to view the list.

Ekampp