Avez-vous vraiment besoin d'une autorisation de confier ou de laravel pour mettre en œuvre votre autorisation?

«Alors… j'ai besoin d'une simple autorisation. Une sorte de rôle d'administrateur, et peut-être le rôle d'éditeur / modérateur. Maintenant, google. Oh! Il existe déjà des packages prêts à l'emploi pour laravel! zizaco / confiez , spatie / laravel-permission et autres! Choisissons-en! »

C’est comme ça que tout se passe. Ensuite, la migration du package ajoute 5 étiquettes à la base de données pour stocker les rôles, les autorisations et leurs relations. Toutes les règles d'autorisation, telles que les rôles 'admin' et 'éditeur' peuvent faire 'éditer les publications' , sont stockées dans ces tableaux. En règle générale, un projet possède de nombreuses copies de la base de données. Copies des développeurs, base (s) de test et production. Par conséquent, toutes ces règles d'autorisation sont forcées de se synchroniser entre les bases de données.

J'ai rencontré quelques projets où il y avait une copie principale des règles dans la base de données de production et le reste a tout copié à partir de là.

L'idée d'utiliser la classe Seeder ( exemple ) est bien meilleure. Vous avez juste besoin de courir

php artisan db:seed AuthSeeder

et vous avez la dernière version des règles dans la base de données. Ainsi, cette classe de semoir devient une sorte de source unique de vérité. Bien, mais cette approche présente encore de nombreux inconvénients:

• Seeder doit être suffisamment intelligent pour non seulement créer des rôles et des autorisations et les connexions entre eux, mais également synchroniser les anciennes versions. C'est-à-dire supprimez ou créez des liens entre les rôles et les autorisations si nécessaire.
• Les règles sont stockées dans la base de données et une synchronisation constante entre elles est requise. Chaque changement de l'exigence du formulaire «les éditeurs ne devraient plus éditer les articles, seulement les publier» entraîne un changement dans le semoir, la synchronisation de la base de code via un git ou quelque chose, et «N'OUBLIEZ PAS DE DÉMARRER AuthSeeder!»
• Les règles d'autorisation peuvent être complexes. Par exemple, une publication peut être éditée non seulement par des éditeurs ou des administrateurs, mais aussi par l'auteur de cette publication. Par conséquent, au lieu d'un simple middleware:

 ['middleware' => ['permission:edit posts']] 

les développeurs doivent utiliser l'autorisation laravel standard:

 class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } } 

Alors peut-être que le moyen le plus simple n'est pas le meilleur?

Cela semble simple: mettez le package, exécutez la migration terminée et c'est parti. Du point de vue d'un soutien de projet à long terme, ce n'est pas le meilleur choix.

Essayons d'analyser de quels projets ont généralement besoin? Système de jeu de rôle simple. Presque toujours un rôle par utilisateur. Administrateur Eh bien, peut-être un autre éditeur ou modérateur. Et ces rôles ont des autorisations. Allons le chemin le plus direct! Ajoutez un nouveau champ à la table des utilisateurs! is_admin ou role . Ensuite, quelques assistants pour la classe User :

 class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} } 

Maintenant, permishen. Laravel fournit deux méthodes de base pour les décrire: les portes et les politiques . Je vais utiliser des portes (il y a encore un petit truc avec une fonction dans une variable, mais pour les amateurs de programmation fonctionnelle ce n'est pas du tout un truc):

  $isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin); // Complex permission Gate::define('edit-post', function(User $user, Post $post) { return $user->id == $post->owner_id || $user->isAdmin(); }); 

Si le projet a besoin de plusieurs rôles par utilisateur, ajoutez simplement la table user_roles et modifiez les assistants de la classe User . Le contenu de la classe seeder pour les packages * trust et cette autorisation basée sur le code sont presque identiques! Mais les règles sont désormais simplement stockées dans le code et il n'est pas nécessaire de les synchroniser en permanence dans les bases de données.

Je ne veux pas dire que ces packages sont inutiles. Cette approche est très utile dans les projets avec un système d'autorisation complexe, où le client lui-même souhaite configurer les rôles ultérieurement. Il existe également des projets avec des autorisations dynamiques. Exemple: forum avec sous-forums. Chaque sous-forum peut avoir ses propres modérateurs, chaque modérateur a des droits définis par l'administrateur dans ce sous-forum. Un autre exemple est le télégramme et ses groupes. C'est la même chose. De tels projets ont vraiment besoin d'un système d'autorisation complexe, stocké dans la base de données, avec tous ses problèmes. Mais la plupart des autres ne le font pas.

La situation avec les packages pour laravel devient similaire à la situation avec les composants pour Delphi (les personnes âgées s'en souviennent). Ils ont mis les paquets sans hésitation - vraiment nécessaires ou non.

Donc, je devrais calculer $ a + $ b dans mon projet ici. Existe-t-il un package Laravel-Sum?

PS Je m'excuse pour les autorisations, mais je n'ai pas trouvé une bonne traduction précise.