Esquema de la base de datos para la ACL

Question

Deseo crear un esquema para una ACL; sin embargo, estoy dividido entre un par de formas de implementarlo.

Estoy bastante seguro de que no quiero lidiar con los permisos en cascada ya que eso genera mucha confusión en el servidor y para los administradores del sitio.

Creo que también puedo vivir con usuarios que solo cumplen una función a la vez. Una configuración como esta permitirá que los roles y permisos se agreguen según sea necesario a medida que el sitio crece sin afectar los roles/reglas existentes.

Al principio iba a normalizar los datos y tener tres tablas para representar las relaciones.

ROLES { id, name } 
RESOURCES { id, name } 
PERMISSIONS { id, role_id, resource_id } 

una consulta para averiguar si un usuario se le permitió algún lugar se vería así:

SELECT id FROM resources WHERE name = ? 
SELECT * FROM permissions WHERE role_id = ? AND resource_id = ? ($user_role_id, $resource->id) 

Entonces me di cuenta de que sólo tendrá alrededor de 20 recursos, cada uno con hasta 5 acciones (crear , actualizar, ver, etc.) y tal vez otros 8 roles. Esto significa que puedo ejercer un flagrante desprecio por la normalización de datos ya que nunca tendré más de un par de cientos de registros posibles.

Entonces, tal vez un esquema como este tenga más sentido.

ROLES { id, name } 
PERMISSIONS { id, role_id, resource_name } 

que me permitiría para buscar registros en una sola consulta

SELECT * FROM permissions WHERE role_id = ? AND permission = ? ($user_role_id, 'post.update') 

Entonces, ¿cuál de ellos es más correcto? ¿Hay otros diseños de esquema para ACL?

Answer 1

En mi experiencia, la pregunta real sobre todo si se rompe a cualquier cantidad de Acceso restricción específica del usuario o no va a ocurrir.

Supongamos, por ejemplo, que está diseñando el esquema de una comunidad y que permite a los usuarios alternar la visibilidad de su perfil.

Una opción es adherirse a un indicador de perfil público/privado y atenerse a amplios controles de permiso preventivos: 'users.view' (vistas de usuarios públicos) vs, digamos, 'users.view_all' (vistas de todos los usuarios , para los moderadores).

Otro implica permisos más refinados, es posible que desee que puedan configurar las cosas para que puedan (a) ser visibles para todos, (b) visibles para sus amigos, (c) mantenerse privadas por completo, y tal vez (d) visible para todos excepto sus bozos seleccionados a mano. En este caso, debe almacenar los datos relacionados con el propietario/acceso para filas individuales, y deberá abstraer en gran medida algunas de estas cosas para evitar materializar el cierre transitivo de un gráfico denso orientado.

Con uno u otro enfoque, he encontrado que añade complejidad en función de edición/asignación se compensa con la facilidad/flexibilidad que resulta en asignar permisos a piezas individuales de datos, y que el siguiente para mejor trabajado:

1. los usuarios pueden tener múltiples funciones
2. Roles y permisos se fusionaron en la misma mesa con una bandera para distinguir los dos (roles/permanentes durante la edición de útiles)
3. roles pueden asignar otras funciones, y las funciones y las permanentes pueden asignar permisos (pero los permisos no pueden asno roles de ign), desde dentro de la misma tabla.

El gráfico orientado resultante se puede extraer en dos consultas, compiladas de una vez por todas en un tiempo razonable utilizando el idioma que esté utilizando, y se almacenan en memoria caché en Memcache o similar para su uso posterior.

A partir de ahí, extraer los permisos de un usuario es una cuestión de verificar qué roles tiene y procesarlos usando el gráfico de permisos para obtener los permisos finales. Compruebe los permisos verificando que un usuario tenga el rol/permiso especificado o no. Y luego ejecute su consulta/problema un error basado en esa verificación de permiso.

Puede ampliar la comprobación de nodos individuales (es decir, check_perms($user, 'users.edit', $node) para "editar este nodo" contra check_perms($user, 'users.edit') para "puede editar un nodo") si es necesario, y tendrá algo muy flexible/fácil de usar para los usuarios finales.

Como lo ilustrará el ejemplo de apertura, tenga cuidado de dirigir demasiado hacia los permisos de nivel de fila. El cuello de botella de rendimiento es menor al verificar los permisos de un nodo individual que al extraer una lista de nodos válidos (es decir, solo aquellos que el usuario puede ver o editar).Aconsejo que no vaya más allá de los indicadores y los campos user_id dentro de las filas si no está (muy) bien versado en la optimización de consultas.

Answer 2

Puede usar un SET para asignar las funciones.

CREATE TABLE permission (
    id integer primary key autoincrement 
    ,name varchar 
    ,perm SET('create', 'edit', 'delete', 'view') 
    ,resource_id integer); 

Answer 3

Esto significa que puedo ejercer flagrante indiferencia para la normalización de datos, ya que nunca tener más de un par cientos de registros posibles.

El número de filas que espera no es un criterio para elegir qué forma normal apuntar. La normalización se refiere a la integridad de los datos. Por lo general, aumenta la integridad de los datos al reducir la redundancia.

La verdadera pregunta a realizar no es "¿Cuántas filas tendré?", Sino "¿Qué tan importante es para la base de datos darme siempre las respuestas correctas?" Para una base de datos que se utilizará para implementar una ACL, diría "Bastante peligroso".

En todo caso, un número bajo de filas sugiere que no necesita preocuparse por el rendimiento, por lo que 5NF debería ser una elección fácil de realizar. Deberá presionar 5NF antes de agregar cualquier número de identificación.

una consulta para averiguar si un usuario se permitió algún lugar se vería como esto:

SELECT id FROM resources WHERE name = ? 
SELECT * FROM permissions 
WHERE role_id = ? AND resource_id = ? ($user_role_id, $resource->id) 

que escribió que, como dos consultas en lugar de utilizar una combinación interna sugiere que usted podría estar por encima de tu cabeza (Eso es una observación, no una crítica.)

SELECT p.* 
FROM permissions p 
INNER JOIN resources r ON (r.id = p.resource_id AND 
          r.name = ?)