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).

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.
2. Buscas una receta que no es tuya, por ejemplo la receta 89, que pertenece al usuario con ID 13.
3. 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.