Los componentes Livewire que leen o modifican recursos protegidos deben aplicar un límite de autorización del lado del servidor.
Usa, siempre que sea posible, una sola protección a nivel de componente en mount() para la pantalla o recurso. No repitas la misma autorización en cada acción cuando mount() ya protege el componente. Añade autorización a nivel de acción solo cuando esa acción interactúe con un recurso o capacidad diferente.
Prefiere la autorización respaldada por políticas para los recursos protegidos. Cuando exista un sujeto de política útil, llama a la política mediante $this->authorize(...), $this->user()->can(...) o el helper de autorización equivalente del proyecto en lugar de crear helpers de acceso específicos del componente que dupliquen la lógica de la política.
Cuando mount() recibe un modelo Eloquent que es un sujeto de política útil, autoriza ese modelo directamente en mount(). Un helper específico del componente que contenga abort_unless(...), abort_if(...), comprobaciones de permisos, comprobaciones de tenant o comprobaciones de funcionalidades no sustituye la política del modelo. Los guards estrictos pueden aplicar esas condiciones adicionales no relacionadas con políticas, pero el componente todavía debe llamar a la política para el modelo protegido.
No exijas $this->authorize(...) solo porque un componente Livewire esté autenticado o se renderice dentro del área admin/app. La autorización es obligatoria cuando el componente lee o modifica un recurso protegido con un sujeto de política útil, como una instancia de modelo, una clase de modelo, un recurso de tenant/team/company o un recurso admin respaldado por permisos.
Las páginas generales autenticadas como dashboards, pantallas de inicio, pantallas de cuenta/perfil del usuario actual, configuraciones a las que cualquier usuario autenticado puede acceder y páginas agregadas sin un recurso protegido específico no necesitan una política ni $this->authorize(...), a menos que el proyecto ya tenga una política o permiso explícito para esa pantalla exacta o que el componente exponga datos protegidos entre usuarios o entre tenants.
No crees una nueva política, permiso o helper específico del componente solo para cumplir esta regla. Si no existe un sujeto de política útil, deja el componente sin autorización por política o usa la ruta, el middleware o el auth guard existentes como límite. Usa abort_unless(...) solo para una condición real no basada en políticas que deba aplicarse del lado del servidor.
Una protección estricta como abort_unless(...) es aceptable cuando no existe un sujeto de política útil. Los flujos públicos de autenticación y los formularios públicos de captación/marketing no requieren autorización por política, a menos que accedan a recursos solo para usuarios autenticados.
// Correct — model resource has a policy subject
public function mount(BillingPlan $billing_plan)
{
$this->authorize('view', $billing_plan);
$this->billingPlan = $billing_plan;
}
// Incorrecto — un guard estricto específico del componente sustituye la política del modelo
public function mount(BillingPlan $billing_plan)
{
$this->authorizeBillingPlanAccess($billing_plan);
}
private function authorizeBillingPlanAccess(BillingPlan $billing_plan): void
{
abort_unless(auth()->user()->hasPermissionTo('retrieve billing plans'), 403);
}
// Correct — current-user profile screen; route/auth middleware is enough unless the project has a specific policy
public function mount()
{
$this->user = auth()->user();
}
// Incorrect — invents authorization for a general dashboard with no protected policy subject
public function mount()
{
$this->authorize('viewDashboard');
}
// Incorrect — protected component has no server-side guard
public function deletePlan()
{
$this->billingPlan->delete();
}
