2012-04-25 21 views
6

Estoy desarrollando una aplicación para nuestra empresa que finalmente tendrá muchas formas de restringir a los usuarios a secciones/módulos particulares. Si bien la aplicación aún es pequeña, me gustaría pasar a un nuevo método de almacenamiento de permisos que, a medida que la aplicación crece, seguirá siendo fácil de mantener y consultar.Almacenamiento de permisos de aplicaciones en una base de datos

Actualmente en nuestra base de datos MySQL tenemos una tabla llamada "usuario" que almacena la identificación del usuario, nombre de usuario y contraseña. En una tabla separada llamada "user_acl" es el siguiente:

user_acl_id 
acl_root 
acl_news_read 
acl_news_write 
acl_news_modify 
acl_reports_read 
acl_reports_write 
acl_reports_modify 
acl_users_read 
acl_users_write 
acl_users_modify 

solamente tenemos 3 módulos en el minuto, pero con el tiempo más se creará y tendrá que ser añadido permisos para cada uno.

En lugar de crear una columna para cada permiso, ¿hay alguna otra forma o el almacenamiento de esta información?

Respuesta

24

Lo haría de esta manera.

table name: permission 
columns: id, permission_name 

y luego puedo asignar varios permisos al usuario usando una de muchos a muchos tabla de relación

table name: user_permission 
columns: permission_id, user_id 

Este diseño me permite añadir tantos permisos como yo quiero, y asignarlo a lo muchos usuarios como yo quiera

Si bien el diseño anterior cumple con su requisito, tengo mi propio método para implementar ACL en mi aplicación. Lo estoy publicando aquí.

Mi método de implementación de ACL es la siguiente:

  1. usuario se le asignará un papel (Admin, invitados, personal, público)
  2. Un papel tendrá uno o varios permisos asignados a ellos (user_write, user_modify, report_read) etc.
  3. Se heredará el permiso del usuario al que pertenece
  4. Se le puede asignar al usuario un permiso manual además del permiso heredado de la función.

Para hacer esto, he creado el siguiente diseño de base de datos.

role 
I store the role name here 
+----------+ 
| Field | 
+----------+ 
| id  | 
| roleName | 
+----------+ 

permission: 
I store the permission name and key here 
Permission name is for displaying to user. 
Permission key is for determining the permission. 
+----------------+ 
| Field   | 
+----------------+ 
| id    | 
| permissionName | 
| permissionKey | 
+----------------+ 

role_permission 
I assign permission to role here 
+---------------+ 
| Field   | 
+---------------+ 
| id   | 
| role_id  | 
| permission_id | 
+---------------+ 

user_role 
I assign role to the user here 
+---------------+ 
| Field   | 
+---------------+ 
| id   | 
| user_id  | 
| role_id  | 
+---------------+ 

user_permission 
I store the manual permission I may allow for the user here 
+---------------+ 
| Field   | 
+---------------+ 
| id   | 
| user_id  | 
| permission_id | 
+---------------+ 

Esto me da más control sobre la ACL. Puedo permitir que los superadmintos otorguen permisos por sí mismos, y así sucesivamente. Como dije, esto es solo para darte la idea.

+0

¿Cómo agregar información adicional acerca del rol como administrador público, etc.? por ejemplo, el administrador tiene algo extra que agregar como nombre de compañía ... ¿y el usuario no tiene este campo? – james

+0

Guardaría información en la entidad relacionada, puede agregar columnas adicionales a la tabla, si desea agregar más información para una función, puede agregar una columna adicional en la tabla de roles, lo mismo vale para la tabla de usuario –

+0

si tengo una tabla de usuarios con los campos username y password.which es genérico para todos los usuarios. y tengo una tabla de miembros con algún campo adicional, como el nombre de la empresa, la dirección, etc. También tengo administrador con más información. ¿Debo utilizar la relación de supertipo/subtipo para el usuario con memebers admin? – james

0

Creo que debe hacer esos permisos en formato jSON.

puede hacer otra tabla con permisos donde puede agregar, modificar, eliminar filas en cualquier momento que desee.

o

cada vez que el usuario se autentica puede almacenar esos permisos en la sesión y pasarlo a las secuencias de comandos.

Mi sugerencia personal es la primera opción.

0

Como dice Ibrahim, crea una nueva tabla específicamente para tus permisos.Asigne un valor numérico a un usuario que represente su nivel de permiso, digamos 1 = leer, 2 = escribir/leer, 3 = modificar/escribir/leer. Luego, en su código, verifique el nivel de permiso adecuado antes de permitir que un usuario realice una tarea específica. Si no tienen el valor requerido (3 para modificar o> = 2 para escribir), entonces bloqueas esa capacidad.

0

creo que usted debe tener cuadros favoritos:

user 
user_x_profile 
profile 
profile_x_function 
function 

Se configura varios perfiles "genéricas" "espectador", "empleado", "director", etc.

Se configura una "función "entrada para cada objeto que desea controlar.

A continuación, vincule las funciones a los perfiles en profile_x_function.

A continuación, asigne uno o más perfiles a cada usuario.

Esto reduce el esfuerzo de administración. Supongamos que desea agregar otra función que solo puedan usar los "gerentes": simplemente agrega una nueva entrada en la tabla de funciones y luego agrega una entrada en la tabla "profile_x_function" que vincula el perfil "manager" con el permiso del perfil del administrador y está disponible para todos los gerentes.

Para consultar el acceso necesitará una combinación de cinco tablas, pero solo está seleccionando un atributo de permiso.

Cuestiones relacionadas