2010-06-12 14 views
5

Actualmente sólo estoy usando algo como esto en la Tabla DB:¿Cuál es la forma más eficiente de crear un sistema de permisos?

access: home,register,login 

Y luego, en cada página:

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

es que hay manera más eficiente de hacerlo con php & MySQL? Es posible que desee obtener acceso incluso a varias partes de una página, por ejemplo, el usuario puede leer una página, pero no le comenta, y no quiero construir un sistema separado para cada módulo.

Respuesta

3

Creo que lo que busca es lista de control de acceso donde modelar su problema en dos cosas: objetos y funciones.

no quiero imponerla pero utilizando un marco es eficiente en mi opinión, el Zend Framework dispone que, para tener una mirada here

También puede buscar alternativas para "PHP ACL", en this SO question.

+0

Zend_Acl es el único ZF que uso en uno de mis sitios y es maravilloso.A menos que desee analizar la teoría de ACLness para obtener más información al respecto (que a menudo me gusta hacer), le recomiendo que la deje allí. – Hans

3

Creé uno con un sistema de permisos "* NIX-type".

Tengo diferentes tipos de permisos para una página (leer, modificar, eliminar, comentar, votar) y asigno un poco a cada uno de ellos.

Así, por ejemplo, que tienen

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

Entonces, si el usuario puede leer, comentar y votar el permiso será de 1 + 16 + 32 = 49

Para comprobar permisos acabo de hacer un bit a bit Y con esos valores.

Por ejemplo user->permissions & USER_CANDELETE para comprobar si el usuario puede eliminar la página (obviamente tengo una función canDelete para eso)

1

Si está utilizando algún tipo de enrutamiento tendrá sentido para hacer su ACL (Lista de Control de Acceso) depende de la ruta que haya definido.

Normalmente corro con una tabla de permisos y una tabla de permisos_personas en una relación HABTM. De esta forma, cuando el enrutamiento coincide, se puede buscar un permiso. Si el usuario no tiene el permiso, se le niega el acceso. Esto se puede mejorar con la comprobación de los diferentes tipos de métodos GET, POST, PUT y DELETE.

Esto es porque me gusta la oportunidad de editar los permisos y la configuración desde la interfaz web, y permitir que otras personas hagan lo mismo (es decir, gente de marketing).

Este es el diagrama:

+-----------------------+ 
| 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 
+-------------------------+ 

Así el usuario 1 no tiene ninguno de los derechos que podrían alterar los registros. Y dado que el enrutamiento define dónde van los diferentes métodos de solicitud, simplemente no se puede POSTAR a los/usuarios para ver la lista.

Cuestiones relacionadas