APRENDER. PRATICAR. EVOLUIR.Guard, provider e permissão
O guard define como um pedido é autenticado, por exemplo usando sessão e cookies. O provider define como obter utilizadores do armazenamento persistente. Em auth:admin, admin identifica uma entrada de guards em config/auth.php; não atribui automaticamente um papel administrativo.
Para diagnosticar identidades inesperadas, reconcilia guard e provider efetivos com os utilizadores obtidos. Depois verifica a permissão da ação sobre o recurso. Alterar o mecanismo de identidade não implementa, por si só, essa regra de negócio.
Login manual e renovação da sessão
Auth::attempt recebe as credenciais e realiza a verificação da password com o valor guardado. Não faças previamente hash da password recebida para a passar a attempt. No fluxo manual documentado, o sucesso é seguido de session()->regenerate() antes do redirecionamento, para tratar a fixação da sessão.
Um campo logged_in=true ou um novo destino de redirect não renova o identificador. Distingue o exemplo manual de um starter kit que já implementa o fluxo; confirma o comportamento existente antes de duplicar lógica.
Logout e estado residual
Auth::logout remove a informação de autenticação da sessão, mas a sequência recomendada inclui invalidar a sessão e regenerar o token CSRF. Redirecionar para o login só muda a navegação; não é evidência de que todos os dados transitórios anteriores foram removidos.
Define que estado deve terminar na sessão atual e observa o contrato completo. Esta sequência não deve ser apresentada como revogação automática de todos os tokens pessoais, todas as sessões noutros dispositivos ou efeitos já confirmados pela aplicação.
Decidir ou continuar numa policy
Num before de policy com o método da capacidade implementado, true autoriza e false recusa antes desse método. Devolve null quando a decisão deve continuar para update ou outra capacidade. O tipo de utilizador também importa: por omissão, visitantes não passam para a regra; um argumento opcional permite que a policy os avalie.
A nulabilidade não concede acesso. Uma policy de artigos públicos deve verificar o estado de publicação e tratar explicitamente utilizadores sem sessão, mantendo a proteção dos artigos privados.
Aplicar a regra no endpoint
O middleware can recebe a capacidade e o parâmetro de recurso, como can:update,invoice. Com binding concluído, uma recusa normal da policy impede a ação e resulta em 403, salvo personalização. A diretiva @can controla o que a vista apresenta; um cliente pode enviar o pedido sem usar esse botão.
Mantém a verificação no servidor para a ação concreta. O teste conceptual de acesso deve incluir identidade válida sobre recurso de outra conta, e não apenas utilizador sem login ou formulário escondido.
Origem e token no Laravel 13
PreventRequestForgery, no grupo web padrão, verifica primeiro a origem do pedido através de Sec-Fetch-Site. Quando a verificação same-origin passa, a camada permite prosseguir sem validar o token; se não passa, a configuração padrão recorre à validação do token. originOnly desativa esse fallback e recusa com 403 quando a origem falha, mesmo que exista token válido.
Considera HTTPS, configuração e eventuais exclusões ao diagnosticar. Conserva @csrf nos formulários previstos para o fluxo de token. Passar esta proteção não autentica nem autoriza a ação.
SPA própria e capacidade de token
No fluxo de autenticação SPA próprio do Sanctum, tokenCan devolve true para pedidos autenticados iniciados pela interface própria. Esse comportamento permite uma chamada uniforme à verificação, mas não prova que existe um token pessoal persistido com a capacidade nem que o utilizador pode alterar qualquer fatura.
Combina a análise da capacidade com a policy sobre identidade e recurso. Se trocar um ID permite operar noutra conta, esconder o ID ou repetir tokenCan não resolve a ausência dessa decisão de acesso.
<?php
// Route excerpt: imports, InvoiceController and policy registration omitted.
Route::patch('/invoices/{invoice}', [InvoiceController::class, 'update'])
->middleware(['auth', 'can:update,invoice']);
// InvoicePolicy excerpt: all users follow the same account/edit rule here.
public function update(User $user, Invoice $invoice): bool
{
return $user->account_id === $invoice->account_id
&& $user->can_edit_invoices;
}
// Separate logout controller excerpt for the current web session.
Auth::logout();
$request->session()->invalidate();
$request->session()->regenerateToken();
O binding resolve a fatura e can:update,invoice aplica a policy antes da ação. A regra exemplifica pertença à conta e permissão de edição; pressupõe tipos coerentes nos IDs, casts adequados e registo da policy. A autorização de entrada e os campos permitidos da alteração continuam a exigir implementação no controller.
O fragmento de logout é separado e limita-se à sessão web atual. São excertos para interpretação; não se pede execução nem se fornece uma aplicação completa.
Armadilhas comuns
Interpretar auth:admin como papel administrativo; devolver false em before quando se pretendia continuar; tornar o utilizador nullable e esquecer a regra de acesso; tratar tokenCan como autorização de todos os recursos; prever sempre 419 quando falta _token.
Tópicos relacionados: Rotas, binding e middleware · Validação e contratos dos pedidos · Blade, saída e recursos de API
Cada controlo responde a uma pergunta diferente: quem está autenticado, qual sessão continua válida, que ação pode executar sobre este recurso e se o pedido passa a proteção contra falsificação. Regista a configuração efetiva antes de inferir o resultado a partir de um nome ou de um único estado HTTP.
Referência: Guards, providers and permissions · Laravel 13.x; PHP 8.3+