Geekly articles weekly

Comment diviser les rôles dans un projet Laravel: un aperçu des packages RBAC

Lors du développement d'un projet Web dans lequel il existe des comptes utilisateurs, la question se pose souvent d'organiser un système de rôles et de droits pour délimiter l'accès à certaines sections et fonctions du système. Dans cet article, nous comparons les packages de contrôle d'accès et résumons le tableau.




Présentation


Dans la version 5.1, Laravel a introduit Auth Gates, une fonction de cadre intégrée pour le contrôle d'accès. Jusqu'à cette époque, je devais utiliser divers packages tiers. Cependant, même maintenant, le programmeur a le choix: tout écrire vous-même ou utiliser un package prêt à l'emploi. La première option est bien adaptée aux petits projets ou aux projets avec un système simple de droits et de rôles. Le second (avec le bon choix de package) permet un réglage plus fin.

Le but de cet article est de passer en revue les packages existants qui implémentent RBAC (Role Based Access Control) - contrôle d'accès basé sur les rôles. Nous préciserons tout de suite que cet article ne prétend pas être la vérité ultime: chaque développeur lui-même doit déterminer de quel package il a besoin (le cas échéant). Remarque: dans cet article, nous considérons RBAC, par conséquent, dans la revue Sentinel, nous ne traitons que cette partie des fonctions disponibles.

Description du paquet


Laravel-permission de Spatie


Lien: https://github.com/spatie/laravel-permission
Documentation: https://docs.spatie.be/laravel-permission/v3
Nombre de téléchargements (au moment de la rédaction): 3,6 M
Version Laravel: de 5.8 pour la version 3
La présence de l'interface: non (vous pouvez utiliser le package )
Basé sur Laravel Auth: oui

CARACTÉRISTIQUES
  1. Disponibilité de commandes artisanales pour créer / attribuer des droits.
  2. Portée finie par rôles et droits.
  3. La possibilité de vérifier les droits des utilisateurs à l'aide d'outils standard en raison du fait que le package utilise Laravel Auth Gates.
  4. Possibilité d'utiliser les directives de lame du package: role (@hasrole), @hasanyrole, @hasallroles, @unlessrole.
  5. Synchronisation des droits et des rôles.

Remarque: lorsque authorize () est appelé pour la stratégie, si l'autorisation a le même nom que la stratégie, cela fonctionnera, pas la stratégie.

Structure DB



Exemples de code

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


Bouncer par joseph silber


Lien: https://github.com/JosephSilber/bouncer
Documentation: https://github.com/JosephSilber/bouncer#introduction
Nombre de téléchargements (au moment de la rédaction): 418K
Version Laravel: à partir du 5.1.20
La présence de l'interface: non (vous pouvez utiliser le package )
Basé sur Laravel Auth: oui

CARACTÉRISTIQUES
  1. Possibilité d'utiliser sans Laravel.
  2. Synchronisation des droits et des rôles.
  3. La capacité d'imposer des restrictions sur les droits (pour une classe particulière de modèle ou pour une instance spécifique.
  4. Délivrance de tous les droits pour «leurs» entités: en utilisant la fonction «toOwn», vous pouvez attribuer tous les droits à une entité qui appartient à l'utilisateur (la comparaison des champs user_id et $ user-> id peut être personnalisée). Vous pouvez limiter les droits accordés à l'aide de la fonction «à».
  5. Prise en charge de la mutualisation (basée sur la fonction scope).
  6. La possibilité d'utiliser la fonction «portée» pour séparer les rôles et les droits en fonction des conditions établies (sur la base d'un identifiant unique) - par exemple, les droits dans le panneau d'administration et la partie publique du site.
  7. Commande artisan de la console pour nettoyer la base de données des autorisations inutilisées.
  8. La possibilité d'interdire rapidement un utilisateur ou de supprimer une interdiction (capacité interdite).

Remarque: vous pouvez créer un rôle et des droits pour celui-ci avec une seule ligne.

Structure DB



Exemples de code

Restriction du droit par classe ou instance de modèle:
 Bouncer::allow($user)->to('edit', Post::class); Bouncer::allow($user)->to('edit', $post);


Délivrance de droits pour «leurs» entités:
 Bouncer::allow($user)->toOwn(Post::class)->to(['view', 'update']);


Laratrust par santigarcor


Lien: https://github.com/santigarcor/laratrust
Documentation: https://laratrust.santigarcor.me/
Nombre de téléchargements (au moment de la rédaction): 601K
Version Laravel: ~ 6.0
Disponibilité de l'interface: non
Basé sur Laravel Auth: non

CARACTÉRISTIQUES
  1. Il s'agit d'une fourchette d' ENTRUST ( https://github.com/Zizaco/entrust ).
  2. Il existe des directives de lame.
  3. En raison du remplacement des commandes Laravel standard par les leurs, il est impossible de travailler avec la directive blade can - vous devrez utiliser $ user-> can ('edit-user') ou la directive permission .
  4. Synchronisation des rôles / droits.
  5. Capacité de disponibilité - vérification simultanée des rôles et des droits.
  6. Middleware prêt.
  7. La mutualisation basée sur les équipes.


Structure DB



Exemples de code
    $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();


Sentinel par Cartalyst


Lien: https://github.com/cartalyst/sentinel
Documentation: https://cartalyst.com/manual/sentinel/3.x
Nombre de téléchargements (au moment de la rédaction): 957K
Version Laravel: 6.2
Disponibilité de l'interface: non
Basé sur Laravel Auth: non

CARACTÉRISTIQUES
  1. Il comprend non seulement les rôles et les droits, mais également tout ce qui concerne l'enregistrement.
  2. Le package est un cadre agnostique, c'est-à-dire il peut être utilisé non seulement dans Laravel - il vous suffit d'installer les dépendances suivantes à l'aide de composer: illuminate / database, illuminate / events, symfony / http-foundation.
  3. À l'aide du module complémentaire Sentinel Expired-Permissions, vous pouvez attribuer des droits sur l'heure.
  4. Prend en charge la mutualisation avec le module complémentaire Sentinel Multitenancy.

Remarque: lors de l'installation sur pur Laravel 6.2 et PostgreSQL, une erreur apparaît lors de la migration: la table des utilisateurs existe déjà. Dans ce cas, vous devez modifier la migration standard:



Structure DB



Exemples de code

 //   $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 par Kodeine


Lien: https://github.com/kodeine/laravel-acl
Documentation: https://github.com/kodeine/laravel-acl/wiki
Nombre de téléchargements (au moment de la rédaction): 170K
Version Laravel: 5.0 et supérieure
Disponibilité de l'interface: non
Basé sur Laravel Auth: non

CARACTÉRISTIQUES
  1. Synchronisation des rôles et des droits.
  2. Droits de succession.
  3. Avoir vos directives de lame: rôle , permission .
  4. Disponibilité du middleware fini.

Remarque Quelques problèmes et solutions lors de la migration:

  • Dans le fichier config / acl, vous devez ajouter l'option users_table avec le nom de la table utilisateur pour garantir une migration stable.
  • Vous devez installer le package «doctrine / dbal» sur Laravel pur afin de «vous faire des amis» avec les migrations standard, sinon une erreur peut se produire lors de la mise à jour des champs.

Structure DB



Exemples de code
 //   $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 par Mateus Junges


Lien: https://github.com/mateusjunges/laravel-acl
Documentation: https://mateusjunges.imtqy.com/laravel-acl/
Nombre de téléchargements (au moment de la rédaction): 1,8 K
Version Laravel: 5.0 et supérieure
Disponibilité de l'interface: oui (formulaires prêts à l'emploi)
Basé sur Laravel Auth: non

CARACTÉRISTIQUES
  1. Portée finie.
  2. Synchronisation des droits pour les groupes.
  3. Avoir vos directives de lame: groupe , @elsegroup, permission , @elsepermission, @ allpermission, @ allgroups, @anypermission, @anygroup
  4. La présence de commandes intégrées permettant à l'artisan de créer des groupes / droits et de les afficher, ainsi que d'afficher les droits des utilisateurs.
  5. Disponibilité d'intergiciels prêts à l'emploi: PermissionMiddleware, GroupMiddleware, HierarchicalPermissions, PermissionOrGroupMiddleware.
  6. Disponibilité de formulaires prédéfinis pour la gestion des rôles.

Structure DB



Tableau récapitulatif





Conclusion


Chacun de ces packages a son propre champ d'application, il est donc impossible de choisir un seul gagnant. Selon nos estimations, Laravel-permission et Bouncer conviennent le mieux à un système de rôles complexe, mais en même temps, il existe un Laravel-ACL de Kodeine avec une hiérarchie de rôles. Laravel-ACL par Mateus Junges est une option «fraîche» et possède suffisamment de fonctionnalités pour créer un ensemble modéré de rôles. Sentinel est une solution universelle avec un tas de fonctionnalités, en plus de la gestion des rôles. Laratrust est pour ceux qui aiment Entrust.

De plus, on ne peut manquer de mentionner les outils standard de Laravel - Portes et politiques. Ils facilitent la différenciation de l'accès aux ressources dans les applications qui ne nécessitent pas de paramètres de droits complexes. Si l'application n'a que quelques rôles ou si la hiérarchie n'est pas nécessaire, vos besoins peuvent être fermés à l'aide de portes et de stratégies.

Liens utiles


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

More articles:


All Articles