La autenticación te dice quién entra; la autorización define qué puede hacer cada quien. Si trabajas con Laravel y necesitas controlar acciones como editar o eliminar, las políticas de acceso son la herramienta que te permite separar esa lógica del controlador y reutilizarla en rutas y vistas.

Por qué necesitas autorización además de autenticación en Laravel

Iniciar sesión y eliminar tu propia pregunta tiene sentido, pero permitir que un usuario borre el contenido de otro es justo lo que debes evitar. Aquí entra el concepto de authorization: validar que la acción solicitada pertenezca a quien la ejecuta.

Una primera idea sería escribir un condicional dentro del controlador, comparando si el recurso pertenece al usuario y, en caso contrario, lanzar un error HTTP de acción no autorizada. Funciona, sí, pero te obliga a repetir la misma lógica en cada acción y en cada controlador.

¿Qué es una política de acceso en Laravel? Es una clase que centraliza las reglas de autorización para un modelo. En lugar de repetir condicionales, defines métodos como update o delete que retornan true o false según si el usuario tiene permiso.

Cómo crear una policy con Artisan para tu modelo

La creación de una política se hace desde la terminal con un solo comando [02:15]. Ejecutas php artisan make:policy seguido del nombre asociado al modelo, en este caso al sistema de preguntas, y Laravel genera el archivo correspondiente.

Dentro de esa clase defines acciones específicas. En el ejemplo se trabajan dos:

• Un método delete que recibe al usuario y a la pregunta, y retorna true si la pregunta le pertenece.
• Un método update con la misma lógica de pertenencia.
• Un segundo parámetro que recibe la instancia del modelo, no un ID, para que Laravel resuelva la relación automáticamente.

La condición es directa: si el user_id de la pregunta coincide con el del usuario autenticado, la acción se autoriza.

Cómo conectar la política con el sistema de rutas

Laravel ofrece una palabra reservada que activa la política desde las rutas. Al definir la acción de actualizar o eliminar, agregas el middleware con el nombre del método y el modelo como argumento.

El flujo queda así:

1. El sistema verifica si estás autenticado.
2. Verifica si tienes permiso para ejecutar la acción.
3. Ejecuta el procedimiento solo si ambas respuestas son afirmativas.

Al probarlo, eliminar una pregunta propia funciona sin problema, pero al intentar borrar la de otro usuario el sistema responde con no estás autorizado para hacer esta acción. Esa es la señal de que la policy está activa.

Cómo ocultar botones según permisos con directivas Blade

Dejar visibles los botones de editar y eliminar en contenido ajeno resulta tentador y confuso. La buena noticia es que Laravel incluye directivas Blade que evalúan la misma política desde la vista.

En el archivo resources/views/preguntas/show envuelves los botones con dos directivas clave:

• @can('update', $pregunta) muestra el botón de editar solo si la política lo permite.
• @can('delete', $pregunta) hace lo mismo con el botón de eliminar.
• La condición evaluada es exactamente la que definiste en la policy.

El resultado es inmediato: en preguntas ajenas los botones desaparecen y solo queda disponible la opción de responder. En las propias, vuelven a aparecer.

¿Para qué sirve la directiva @can en Blade? Evalúa una política antes de renderizar un bloque de la vista. Si el usuario no tiene permiso, el contenido no se muestra, evitando que vea acciones que no puede ejecutar.

Cómo agregar lógica adicional a una policy según el estado del recurso

La autorización no siempre depende solo de la propiedad. A veces el estado del recurso también importa. Imagina una pregunta que ya tiene respuestas: editarla podría cambiar el sentido de toda la conversación y dejar respuestas sin coherencia.

Para cubrir ese escenario, dentro del método update de la policy puedes encadenar más condiciones. La lógica que se aplica combina dos verificaciones:

• Que la pregunta pertenezca al usuario autenticado.
• Que la pregunta no tenga respuestas ni comentarios asociados.

Se usa un operador lógico para unir ambas reglas y se retorna el resultado. Si la pregunta es tuya pero ya recibió interacción, el botón de editar desaparece automáticamente.

Qué pasa cuando el recurso ya tiene interacción

Al probarlo en el proyecto, una pregunta nueva sin respuestas permite editarse sin restricción. En el momento en que alguien deja un comentario o una respuesta, el botón se oculta y, si intentas forzar la acción, recibes el mensaje esta acción no está autorizada.

La eliminación, en cambio, sigue habilitada porque la regla aplicada en delete solo evalúa la propiedad. Cada acción puede tener su propio nivel de exigencia dentro de la misma policy.

Controlar lo que cada usuario puede hacer es una práctica básica de cualquier sistema profesional. Como reto, replica esta misma lógica en el módulo de blog y comparte en los comentarios cómo resolviste las reglas de edición y eliminación.