Cargando…

Esto está tardando más de lo esperado.

Estándares de código

Laravel Policies

Estos son los estándares que aplica el analizador. Cada regla dice qué revisa y por qué existe.

Todos los estándares

Reglas generales

  • Las políticas de la aplicación host viven en app/Policies/; las políticas del paquete viven en el directorio src/Policies/ del paquete
  • Solo extiende BasePolicy cuando el modelo tiene su propio CRUD independiente en el frontend de administración (registrado mediante Laravel Front). BasePolicy valida hasPermissionTo($name) contra los permisos almacenados en la base de datos; si no hay CRUD, el permiso no existe y no hay motivo para crearlo.
  • No deduzcas que a un modelo le falta un CRUD independiente solo porque una política añade lógica de negocio como && $model->can_be_deleted o && ! $instance->is_paid. Verifica evidencia en rutas/recursos como Route::front('ModelName'), un recurso app/Front/Resources/ModelName.php, o un permiso explícito antes de marcar un error en extends BasePolicy.
  • Cuando un modelo no tiene su propio CRUD (p. ej. BillingPrice, BillingPriceVariation), la política solo maneja lógica de negocio (p. ej. "no se puede eliminar si tiene hijos") sin comprobar permisos del usuario por nombre. El acceso se hereda del permiso del modelo padre (p. ej. si el usuario tiene el permiso plans, tiene acceso a precios y variaciones).
  • No registres políticas manualmente en AppServiceProvider. Laravel detecta automáticamente las políticas que siguen la convención de nombres App\Policies\{Model}Policy. Las políticas de paquetes son la excepción: la autodetección solo asigna App\Models\X a App\Policies\XPolicy, así que el service provider del paquete las registra con Gate::policy().
  • Prefiere las políticas para reglas reutilizables de autorización y acceso vinculadas a modelos o recursos protegidos. No crees helpers ad hoc del componente como canAccessVisitor() o canManageResource() para contener lógica de autorización cuando exista un sujeto de política útil; coloca la regla en la política y llámala a través de la autorización de Laravel (authorize, can, @can, o helpers equivalentes del proyecto).
  • Las comprobaciones inline son aceptables para estado local de la UI, flujos públicos o guardas puntuales sin un sujeto de política útil, pero el acceso a recursos protegidos debe usar por defecto autorización respaldada por políticas.
  • Cuando una política aplica una regla de negocio sensible a la persistencia, acompáñala con una red de seguridad en un observer para la misma regla.
  • Cuando la autorización de borrado tenga lógica de negocio (p. ej. "no se puede eliminar si tiene hijos"), expón esa lógica como el accessor can_be_deleted en el modelo. La política delete() y el observer deleting() leen $model->can_be_deleted en lugar de duplicar la condición.
Weblabor Logo Desarrollado por Weblabor