Geekly articles weekly

Cómo dividir roles en un proyecto Laravel: una descripción general de los paquetes RBAC

Cuando se desarrolla un proyecto web en el que hay cuentas de usuario, a menudo surge la pregunta de organizar un sistema de roles y derechos para delimitar el acceso a ciertas secciones y funciones del sistema. En este artículo, comparamos los paquetes de control de acceso y resumimos la tabla.




Introduccion


En la versión 5.1, Laravel introdujo Auth Gates, una función de marco incorporada para el control de acceso. Hasta este momento, tuve que usar varios paquetes de terceros. Sin embargo, incluso ahora, el programador tiene una opción: escribir todo usted mismo o usar algún paquete listo para usar. La primera opción es adecuada para proyectos pequeños o proyectos con un sistema simple de derechos y roles. El segundo (con la elección correcta del paquete) permite un ajuste más preciso.

El propósito de este artículo es revisar los paquetes existentes que implementan RBAC (Control de acceso basado en roles): control de acceso basado en roles. Aclararemos de inmediato que este artículo no pretende ser la verdad última: cada desarrollador debe determinar qué paquete necesita (si es que lo hace). Nota: en este artículo, estamos considerando RBAC, por lo tanto, en la revisión de Sentinel, nos ocupamos solo de esta parte de las funciones disponibles.

Descripción del paquete


Permiso Laravel por Spatie


Enlace: https://github.com/spatie/laravel-permission
Documentación: https://docs.spatie.be/laravel-permission/v3
Número de descargas (al momento de escribir): 3.6M
Versión Laravel: desde 5.8 para la versión 3
La presencia de la interfaz: no (puede usar el paquete )
Basado en Laravel Auth: sí

Caracteristicas
  1. Disponibilidad de comandos artesanales para crear / asignar derechos.
  2. Alcance terminado por roles y derechos.
  3. La capacidad de verificar los derechos de los usuarios utilizando herramientas estándar debido al hecho de que el paquete utiliza puertas de autenticación Laravel.
  4. Posibilidad de usar directivas blade del paquete: role (@hasrole), @hasanyrole, @hasallroles, @unlessrole.
  5. Sincronización de derechos y roles.

Nota: cuando se llama a authorize () para la política, si el permiso tiene el mismo nombre que la política, funcionará, no la política.

Estructura DB



Ejemplos de código

//    $user->givePermissionTo('edit articles'); //    $user->assignRole('writer', 'admin'); //       $user->assignRole(['writer', 'admin']); //    $role->givePermissionTo('edit articles');


Gorila de joseph silber


Enlace: https://github.com/JosephSilber/bouncer
Documentación: https://github.com/JosephSilber/bouncer#introduction
Número de descargas (al momento de escribir): 418K
Versión Laravel: desde 5.1.20
La presencia de la interfaz: no (puede usar el paquete )
Basado en Laravel Auth: sí

Caracteristicas
  1. Posibilidad de usar sin Laravel.
  2. Sincronización de derechos y roles.
  3. La capacidad de imponer restricciones a los derechos (para una clase particular de modelo o para una instancia específica.
  4. Emisión de todos los derechos para "sus" entidades: mediante la función "toOwn", puede emitir todos los derechos para una entidad que pertenece al usuario (la comparación de los campos user_id y $ user-> id se puede personalizar). Puede limitar los derechos otorgados mediante la función "a".
  5. Soporte multitenancy (basado en la función de alcance).
  6. La capacidad de usar la función de "alcance" para separar roles y derechos dependiendo de las condiciones establecidas (basadas en un identificador único), por ejemplo, derechos en el panel de administración y la parte pública del sitio.
  7. Comando artesanal de consola para limpiar la base de datos de permisos no utilizados.
  8. La capacidad de prohibir rápidamente a un usuario o eliminar una prohibición (habilidad prohibida).

Nota: puede crear un rol y derechos para él con solo una línea.

Estructura DB



Ejemplos de código

Restricción del derecho por clase de modelo o instancia:
 Bouncer::allow($user)->to('edit', Post::class); Bouncer::allow($user)->to('edit', $post);


Emisión de derechos para "sus" entidades:
 Bouncer::allow($user)->toOwn(Post::class)->to(['view', 'update']);


Laratrust por santigarcor


Enlace: https://github.com/santigarcor/laratrust
Documentación: https://laratrust.santigarcor.me/
Número de descargas (al momento de escribir): 601K
Versión Laravel: ~ 6.0
Disponibilidad de interfaz: no
Basado en Laravel Auth: no

Caracteristicas
  1. Esta es una bifurcación de ENTRUST ( https://github.com/Zizaco/entrust ).
  2. Hay directivas de cuchillas.
  3. Debido a la sustitución de los comandos estándar de Laravel por los suyos, es imposible trabajar con la directiva de cuchillas can : deberá usar $ user-> can ('edit-user') o la directiva de permisos .
  4. Sincronización de roles / derechos.
  5. Capacidad de disponibilidad: verificación simultánea de roles y derechos.
  6. Middleware listo.
  7. Multiempresa basada en equipos.


Estructura DB



Ejemplos de código
    $user->hasRole(['owner', 'admin']); $user->can(['edit-user', 'create-post']); $user->hasRole('owner|admin'); $user->can('edit-user|create-post');   $user->owns($post) //   $post->user_id   $owner = new Role(); $owner->name = 'owner'; $owner->display_name = 'Project Owner'; // optional $owner->description = 'User is the owner of a given project'; // optional $owner->save();


Centinela de Cartalyst


Enlace: https://github.com/cartalyst/sentinel
Documentación: https://cartalyst.com/manual/sentinel/3.x
Número de descargas (al momento de escribir): 957K
Versión Laravel: 6.2
Disponibilidad de interfaz: no
Basado en Laravel Auth: no

Caracteristicas
  1. Incluye no solo roles y derechos, sino también todo lo relacionado con el registro.
  2. El paquete es un marco agnóstico, es decir se puede usar no solo en Laravel: solo necesita instalar las siguientes dependencias usando composer: illuminate / database, illuminate / events, symfony / http-foundation.
  3. Usando el complemento Sentinel Caducado-Permisos, puede emitir derechos a tiempo.
  4. Admite Multitenancy con el complemento Sentinel Multitenancy.

Nota: cuando se instala en Laravel 6.2 puro y PostgreSQL, aparece un error durante la migración: la tabla de usuarios ya existe. En este caso, debe cambiar la migración estándar:



Estructura DB



Ejemplos de código

 //   $user = Sentinel::findById(1); $role = Sentinel::findRoleByName('Subscribers'); $role->users()->attach($user); //   $admin = Sentinel::inRole('admin'); //   $user->permissions = [ 'user.create' => true, 'user.delete' => false, ]; $user->save(); //   $user->hasAccess(['user.create', 'user.update']); Sentinel::hasAnyAccess(['user.admin', 'user.update']);


Laravel-ACL por Kodeine


Enlace: https://github.com/kodeine/laravel-acl
Documentación: https://github.com/kodeine/laravel-acl/wiki
Número de descargas (al momento de escribir): 170K
Versión Laravel: 5.0 y superior
Disponibilidad de interfaz: no
Basado en Laravel Auth: no

Caracteristicas
  1. Sincronización de roles y derechos.
  2. Derechos de herencia.
  3. Tener sus directivas blade: rol , permiso .
  4. Disponibilidad de middleware terminado.

Nota Algunos problemas y soluciones durante la migración:

  • En el archivo config / acl, debe agregar la opción users_table con el nombre de la tabla de usuario para garantizar una migración estable.
  • Debe instalar el paquete "doctrine / dbal" en Laravel puro para "hacer amigos" con las migraciones estándar, de lo contrario, puede producirse un error al actualizar los campos.

Estructura DB



Ejemplos de código
 //   $permissionInternship = Permission::create([ 'name' => 'internships', 'slug' => [ //   'create' => true, 'view' => true, 'update' => true, 'delete' => true, ], 'description' => 'manage internships' ]); $permissionStudent = Permission::create([ 'name' => 'internships.student', 'slug' => [ //     'create' => false, ], //   'inherit_id' => $permissionInternship->getKey(), 'description' => 'student internship permissions' ]);


Laravel-acl por Mateus Junges


Enlace: https://github.com/mateusjunges/laravel-acl
Documentación: https://mateusjunges.imtqy.com/laravel-acl/
Número de descargas (al momento de escribir): 1.8K
Versión Laravel: 5.0 y superior
Disponibilidad de interfaz: sí (formularios preparados)
Basado en Laravel Auth: no

Caracteristicas
  1. Alcance terminado.
  2. Sincronización de derechos para grupos.
  3. Tener sus directivas blade: grupo , @elsegroup, permiso , @elsepermission, @ allpermission, @ allgroups, @anypermission, @anygroup
  4. La presencia de comandos incorporados para que artesano cree grupos / derechos y los muestre, así como para mostrar los derechos de usuario.
  5. Disponibilidad de middleware listo para usar: PermissionMiddleware, GroupMiddleware, HierarchicalPermissions, PermissionOrGroupMiddleware.
  6. Disponibilidad de formularios predefinidos para la gestión de roles.

Estructura DB



Tabla resumen





Conclusión


Cada uno de estos paquetes tiene su propio campo de aplicación, por lo que es imposible elegir un solo ganador. Según nuestras estimaciones, el permiso Laravel y Bouncer son los más adecuados para un sistema de roles complejo, pero al mismo tiempo existe un Laravel-ACL de Kodeine con una jerarquía de roles. Laravel-ACL de Mateus Junges es una opción "nueva" y tiene suficiente funcionalidad para construir un conjunto moderado de roles. Sentinel es una solución universal con muchas funciones, además de la gestión de roles. Laratrust es para aquellos que les gusta Entrust.

Además, no se puede dejar de mencionar las herramientas estándar de Laravel: puertas y políticas. Facilitan la diferenciación del acceso a los recursos en aplicaciones que no requieren configuraciones de derechos complejas. Si la aplicación solo tiene unos pocos roles o no se necesita una jerarquía, entonces sus necesidades se pueden cerrar con Gates y Políticas.

Enlaces utiles


Source: https://habr.com/ru/post/481796/

More articles:


All Articles