Políticas de acceso en Laravel con Artisan

Curso de Estándares y Buenas Prácticas para API REST con Laravel

Contenido del curso

Buenas prácticas a nivel general

Creación del proyecto

Planificación y mantenimiento

Funciones de seguridad

API Testing

API Breaking Changes

Conclusiones

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:27

Políticas de acceso en Laravel con Artisan

Curso de Estándares y Buenas Prácticas para API REST con Laravel

Clase 18 de 29

Clase 18 / 29

Recursos

Las políticas de acceso en Laravel resuelven un problema crítico de seguridad: evitar que cualquier usuario autenticado pueda eliminar o actualizar recetas que no le pertenecen. Aquí aprendes a crear, registrar y aplicar policies siguiendo el estándar de Laravel para mantener tu código limpio y seguro.

¿Qué problema de seguridad resuelven las policies en Laravel?

Imagina que tu API permite a cualquier usuario logueado borrar la receta de otra persona. Ese es exactamente el agujero que vamos a tapar. La regla que queremos definir es simple: solo puedes actualizar o eliminar tus propias recetas.

En lugar de meter un if gigante dentro del controlador para validar al dueño, aislamos esa lógica en un archivo de política. Así el controlador queda enfocado en orquestar la petición, y la regla de autorización vive en su propio espacio, lista para crecer cuando necesites lógica más avanzada.

¿Qué es una policy en Laravel? Es una clase que centraliza las reglas de autorización para una entidad. En vez de validar permisos en cada controlador, defines métodos como update o delete que devuelven true o false según el usuario y el recurso.

¿Cómo crear una policy con Artisan y asociarla a una entidad?

Desde la terminal de Visual Studio Code corres el comando que genera el archivo dentro de la carpeta app. La instrucción usa php artisan make:policy seguida del nombre, y aquí entra una decisión clave: respetar el estándar de Laravel.

El nombre debe seguir el patrón EntidadPolicy. Por ejemplo, si la entidad es Receta, el archivo se llama RecetaPolicy. Mantener este estándar permite que Laravel descubra automáticamente la política sin necesidad de registrarla manualmente en el AuthServiceProvider.

Dentro del archivo generado escribes los métodos de autorización. Cada método recibe dos parámetros: el usuario autenticado y la entidad sobre la que se actúa.

update($user, $receta): compara el ID del usuario con el user_id de la receta.
delete($user, $receta): aplica la misma lógica para borrado.
Ambos retornan un booleano (true o false).

El corazón de la validación es esta comparación: si el ID del usuario logueado coincide con el user_id de la receta, devuelve true. Si no, devuelve false. Puedes incluso forzar el tipo de retorno a bool para que el código hable por sí solo.

¿Por qué seguir el estándar EntidadPolicy te ahorra trabajo?

Laravel recomienda nombrar el archivo con la entidad seguida de la palabra Policy. Cuando lo haces, el framework detecta el archivo automáticamente y lo asocia con su modelo correspondiente. No necesitas registrar nada en el AuthServiceProvider porque el descubrimiento es automático.

Si rompes la convención y nombras el archivo de otra forma, sí tendrías que ir al provider y registrar manualmente la relación entre modelo y policy. El estándar te ahorra ese paso.

¿Cómo invocar la policy desde el controlador con authorize?

Una vez creado el archivo, vuelves al controlador de recetas y revisas qué acciones necesitan protección:

Ver recetas: cualquiera puede.
Crear recetas: cualquiera puede.
Actualizar y eliminar: solo el dueño.

Para las dos últimas usas el sistema de autorización integrado. Llamas a $this->authorize('update', $receta) antes de ejecutar la actualización, y $this->authorize('delete', $receta) antes del borrado. El primer argumento es el nombre del método definido en la policy; el segundo es la entidad sobre la que validamos.

El código se vuelve autoexplicativo: estás autorizado a actualizar esta receta, estás autorizado a eliminar esta receta. Y todo se verifica contra el usuario que está logueado mediante el token de autenticación.

¿Qué hace exactamente $this->authorize() en Laravel? Ejecuta el método correspondiente de la policy asociada a la entidad. Si retorna true, el flujo continúa. Si retorna false, Laravel lanza una excepción de no autorizado.

¿Cómo probar la policy desde Postman con dos usuarios distintos?

La prueba es sencilla y demuestra que la regla funciona en ambos sentidos. En la clase anterior se creó la receta con ID 103, asociada al usuario logueado (ID 1).

Envías un DELETE a /103 con el token de autenticación. Como la receta te pertenece, la operación se ejecuta sin problemas.
Buscas una receta que no es tuya, por ejemplo la receta 89, que pertenece al usuario con ID 13.
Envías un DELETE a /89 con tu mismo token y el sistema responde con un error claro: "you are not authorized".

Ese mensaje es exactamente la señal que queríamos. Confirma que la policy intercepta la petición, compara IDs y bloquea el acceso cuando el recurso pertenece a otra persona.

Habilidades, conceptos y datos clave de la clase

Policies de Laravel: clases que aíslan la lógica de autorización por entidad, manteniendo los controladores limpios.
Comando php artisan make:policy: genera el archivo en app siguiendo el patrón EntidadPolicy.
Convención de nombres: usar EntidadPolicy.php permite el descubrimiento automático sin registrar nada en AuthServiceProvider.
Método authorize() en el controlador: invoca la policy pasando el nombre del método y la entidad.
Validación por user_id: comparar el ID del usuario autenticado contra el user_id del recurso es el patrón base de pertenencia.
Retorno booleano: los métodos de policy devuelven true o false; puedes forzar el tipo bool para mayor claridad.
Pruebas con Postman: usar el token de autenticación para validar tanto el caso permitido (receta 103, usuario 1) como el bloqueado (receta 89, usuario 13).

Ahora te toca a ti: crea tu propia policy, sigue el estándar de Laravel y prueba ambos escenarios desde Postman. Cuéntame en los comentarios qué entidad protegiste primero.

Comentarios (6)6 comentarios

Jayder Caceres

Hace 3 años

Ah! aqui solucionan el problema de que cualquier usuario puede editar cualquier receta, gracias profe...

Harold German Granados Guerrero

exacto $user->id === $recipe->user_id

Excelenteeee, superrr, Pero como seria que tanto el autor quien creo la receta o el admin pueda eliminar el dato... Seria super super un video donde incluyan roles: admin, usuario, cajeros

Mario Zamora

Hace 2 años

En Laravel hay librerías como Spatie para administrar roles y permisos:

Kenneth Angulo L

Clarísima la explicación del profesor sobre las policies: Aislamos el IF, la receta es tuya sí o no, directo al punto.

Comparto tambien otra logica de validacion:

return $recipe->user()->is($user);

tambien nos regresara true or false

Arik Fernando Miguel Samudio Martínez

Con Laravel 11 tuve que poner (dentro del controller)

use Illuminate\Support\Facades\Gate;

Gate::authorize('update', $recipe);

Gate::authorize('delete', $recipe);

Juan Pablo Campuzano Monsalve

Gracias, también estoy en Laravel 11 e intenté muchas cosas, pero solo me funcionó tu solución. Muchas gracias!

Guillermo Mendizábal

Tuve que agregar use Illuminate\Foundation\Auth\Access\AuthorizesRequests; y el trait use AuthorizesRequests; No sé porque el profesor no tuvo que hacerlo

José Jesús Palacios

Estarás utilizando Laravel 11.x


// Laravel 10.x
namespace App\Http\Controllers;

use Illuminate\Foundation\Auth\AuthorizeRequests;
use Illuminate\Foundation\Auth\ValidatesRequest;
use Illuminate\Routing\Controller as BaseController;

class <u>Controller</u> extends <u>BaseController</u>
{
&#x20; use AuthorizeRequests, ValidatesRequest;
}

En Laravel 11.x, esto se hace en cada controlador específico que necesite de una autorización.

Por ejemplo:

// RecipeController.php
...

use Illuminate\Foundation\Auth\AuthorizeRequests;

class <u>RecipeController</u> extends <u>Controller</u>
{
&#x20; use AuthorizesRequests;

&#x20; ....
}


// Laravel 10.x

namespace App\Http\Controllers;



use Illuminate\Foundation\Auth\AuthorizeRequests;

use Illuminate\Foundation\Auth\ValidatesRequest;

use Illuminate\Routing\Controller as BaseController;



class Controller extends BaseController

{

&#x20; use AuthorizeRequests, ValidatesRequest;

}


// RecipeController.php



...



use Illuminate\Foundation\Auth\AuthorizeRequests;



class RecipeController extends Controller

{

&#x20; use AuthorizesRequests;



&#x20; ...

}

Excelente clase!

Buenas prácticas a nivel general

Buenas prácticas para diseñar una API REST

¿Qué son los HTTP Status Codes?

Qué hace cada método HTTP

Creación del proyecto

Migrações e relações de dados em Laravel

Factories y seeders para poblar tu API en Laravel

Consultas API con Laravel: Rutas y Controladores

Consultas con relaciones en Laravel API

Planificación y mantenimiento

Planificación de rutas REST en Laravel

Recursos y colecciones en Laravel API

Recursos anidados en Laravel API

Cómo reducir 932 consultas con Telescope

CRUD de Recetas con Laravel y Symfony en Visual Studio Code

Validación de Datos en Aplicaciones Web con Laravel

Funciones de seguridad

Autenticación vs. autorización

Proteger rutas de API con Sanctum

Ruta de login y tokens con Sanctum

Corrección de bugs de seguridad en aplicaciones web

Políticas de acceso en Laravel con Artisan

Upload e validação de imagens em Laravel

Qué es autenticación en la web

API Testing

Automatiza pruebas de API en Laravel

Testing de Módulos Administrativos en Visual Studio Code

Testing de recetas con PHP Artisan

Pruebas de Creación de Datos en Aplicaciones Web

Test de actualización de recetas en Laravel

API Breaking Changes

Versionado de API en Laravel con v1 y v2

Desarrollo de API con TDD: Implementación de Versión 2

Conclusiones

Desarrollo de API RESTful con Laravel: Buenas Prácticas y Seguridad

Buenas prácticas finales para tu API en Laravel

Políticas de acceso en Laravel con Artisan