Workshop: ACL no Laravel

O workshop foi tocado a quatro mãos por Danilo Sampaio e Lucas Souza (Virgo), com o Virgo compartilhando a tela e o Danilo mediando perguntas do chat ao vivo — clima de aula mesmo, com direito a bug ao vivo, debug em tempo real e a plateia ajudando a achar o erro na regra.

Destaques

Modelagem inicial explicada com a analogia do crachá de evento (visitante x imprensa): papéis (roles) e permissões (permissions) num relacionamento N-para-N, e usuário vinculado a um papel.
Implementação nível 1 com Gates puros no AppServiceProvider: Gate::define('access_role', fn ($user) => ...) e Gate::authorize('access_role') no controller, barrando rota por rota.
Evolução para Policies: sail artisan make:policy RolePolicy -m, convenção de nome (Model + Policy) para discovery automático, métodos padrão de CRUD (viewAny, view, create, update, delete) e uso de Gate::authorize ou authorizeResource manual (já que o Laravel 11 removeu esse método do controller).
Diretiva Blade @can('access_role') para sumir itens de menu sem acesso, e uso de Gate::allows() + redirect()->back() para UX mais amigável que o 403 padrão.
Hook Gate::before para implementar um "modo Deus" de admin que passa por cima de qualquer regra — com o cuidado de não travar o fluxo caso a condição esteja mal escrita (bug ao vivo: comparação errada de user_id com role_id).
Terceiro nível: permissões vindas do banco de dados, montando gates dinamicamente em loop a partir da tabela permissions relacionada a roles via pivô, checagem de execução via console (App::runningInConsole()) e discussão sobre custo de query (a query de permissões roda uma vez por request, não uma vez por gate).
Fechamento com um middleware próprio (AuthorizeResource) que lê o nome da rota (module.index, module.create etc.) para deduzir a permissão esperada, recriando o antigo authorizeResource() do controller sem a injeção de dependência que ele fazia.

Profundidade tecnica

A aula foi longe o suficiente para expor decisões de arquitetura reais, não só sintaxe: a diferença entre travar a regra no código (Gate/Policy) versus no banco (mais flexível, mas com um gate "escondido" que dificulta grep), o trade-off de usar Gate::before (regra "mata todas" no topo) e cuidados de performance como evitar SELECT * na query de permissões e estratégias (e riscos) de cache por usuário logado. Perguntas da plateia levaram a discussões extras sobre modelagem multi-entidade (médico/paciente/fornecedor com tabelas próprias) e multi-tenant (permissão por usuário e por instituição), tratadas como fora do escopo do workshop e reservadas para a formação completa.

Faça parte do Clã

Se esse tipo de aula prática, direto ao ponto e com gente respondendo dúvida em tempo real é a sua praia, é exatamente isso que rola toda semana no Clã Beer and Code. Lá você tem acesso a encontros como esse, mentoria técnica de quem já resolveu esses problemas em produção, e uma comunidade de devs Laravel/PHP para trocar ideia, tirar dúvida e evoluir junto. Bora entrar no Clã?

▪ Clã Beer and Code

Faça parte do Clã. Construa o que importa.

Engenharia de IA virou profissão, e se aprende construindo, não assistindo. O Clã Beer and Code é o ambiente onde isso acontece ao vivo, toda semana: RAG, agentes, observabilidade e LLMOps em projetos reais, ao lado de quem já está em produção. É pago, é assinatura, e é exatamente o ambiente que estes encontros dão uma amostra.

Entrar no Clã