Você realmente precisa de confiança ou permissão de laravel para implementar sua autorização?

“Então ... eu preciso de uma autorização simples. Algum tipo de função administrativa, e talvez a função de editor / moderador. Agora pesquise no google. Oh! Já existem pacotes prontos para o laravel! zizaco / confiar , permissão espacial / laravel e outros! Vamos escolher alguns!

É assim que tudo acontece. Em seguida, a migração do pacote adiciona 5 rótulos ao banco de dados para armazenar funções, permissões e seus relacionamentos. Todas as regras de autorização, como as funções 'admin' e 'editor' podem 'editar postagens' , são armazenadas nessas tabelas. Normalmente, um projeto possui muitas cópias do banco de dados. Cópias de desenvolvedores, base (s) de teste e produção. Como resultado, todas essas regras de autorização são forçadas a sincronizar entre bancos de dados.

Eu conheci alguns projetos em que havia uma cópia principal das regras no banco de dados de produção e o restante copiou tudo a partir daí.

A ideia de usar a classe Seeder ( exemplo ) é muito melhor. Você só precisa correr

php artisan db:seed AuthSeeder

e você tem a versão mais recente das regras no banco de dados. Assim, essa classe de semeadora se torna um tipo de Fonte Única da Verdade. Bom, mas ainda existem muitos inconvenientes nessa abordagem:

• O semeador deve ser inteligente o suficiente para não apenas criar funções e permissões e as conexões entre eles, mas também sincronizar versões antigas. I.e. remova ou crie links entre funções e permissões, se necessário.
• As regras são armazenadas no banco de dados e é necessária uma sincronização constante entre elas. Cada alteração no requisito do formulário "editores não devem mais editar postagens, apenas publicá-las" leva a uma alteração no semeador, sincronização da base de código por meio de um git ou algo assim e "NÃO ESQUEÇA DE INICIAR O AuthSeeder!"
• As regras de autorização podem ser complexas. Por exemplo, uma publicação pode ser editada não apenas por editores ou administradores, mas também pelo autor desta publicação. Portanto, em vez de um middleware simples:

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

os desenvolvedores devem usar a autorização padrão do laravel:

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

Então, talvez a maneira mais fácil não seja a melhor?

Parece simples: coloque o pacote, execute a migração concluída e pronto. Do ponto de vista do suporte a longo prazo ao projeto, essa não é a melhor escolha.

Vamos tentar analisar quais projetos geralmente precisam? Sistema simples de interpretação de papéis. Quase sempre uma função por usuário. Administrador Bem, talvez outro editor ou moderador. E essas funções têm algumas permissões. Vamos seguir o caminho mais direto! Adicione um novo campo à tabela de usuários! is_admin ou função . Depois, alguns ajudantes da classe Usuário :

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

Agora permishen. O Laravel fornece dois métodos básicos para descrevê-los: Gates e Policies . Vou usar gates (ainda existe um pequeno truque com uma função em uma variável, mas para os amantes da programação funcional isso não é um truque):

  $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(); }); 

Se o projeto precisar de várias funções por usuário, basta adicionar a tabela user_roles e alterar os auxiliares da classe User . O conteúdo da classe seeder para os pacotes * trust e essa autorização baseada em código são quase idênticos! Mas agora as regras são simplesmente armazenadas no código e não há necessidade de sincronizá-las constantemente nos bancos de dados.

Eu não quero dizer que esses pacotes são inúteis. Essa abordagem é muito útil em projetos com um sistema de autorização complexo, em que o próprio cliente deseja configurar funções posteriormente. Também há projetos com permissões dinâmicas. Exemplo: fórum com subforums. Cada sub-fórum pode ter seus próprios moderadores, cada moderador tem direitos definidos pelo administrador neste sub-fórum. Outro exemplo é o telegrama e seus grupos. Existe a mesma coisa. Tais projetos realmente precisam de um sistema de autorização complexo, armazenado no banco de dados, com todos os seus problemas. Mas a maioria dos outros não.

A situação com pacotes para laravel se torna semelhante à situação com componentes para Delphi (lembram-se os idosos). Eles colocam os pacotes sem hesitação - realmente necessários ou não.

Então, eu teria que calcular $ a + $ b no meu projeto aqui. Existe algum pacote laravel-sum?

PS Peço desculpas pelas permissões, mas não encontrei uma boa tradução precisa.