Contenido del curso
Diseño de un foro
- 5

Flujo completo de Laravel: ruta, controlador, modelo y vista
07:55 min - 6

Diseño home en Laravel con Tailwind CSS
09:48 min - 7

Desarrollo de página de detalles con rutas dinámicas en Laravel
07:43 min - 8

Creación de componentes Blade para plantillas reutilizables en Laravel
07:11 min - 9

Pregunta con respuestas dinámicas en Laravel
05:19 min - 10

Relaciones polimorfas para comentarios en Laravel
06:33 min
Livewire
Optimización
CRUD
Detalles finales
Control de acceso con middleware en Laravel
Resumen
Controlar quién puede ver, crear o eliminar contenido es la base de cualquier proyecto serio en Laravel. Aquí aprenderás a implementar autenticación de usuarios con middleware, directivas Blade y helpers nativos para diferenciar entre visitantes y usuarios registrados dentro de tu sistema de preguntas y respuestas.
¿Cómo proteger rutas con middleware en Laravel?
El primer paso es bloquear el acceso a las acciones críticas: crear, editar, actualizar, eliminar y responder. Para eso usamos el middleware auth que Laravel ofrece de forma nativa.
La idea es simple: si no iniciaste sesión, no puedes tocar la base de datos. Aplicas el middleware sobre cada ruta sensible y Laravel se encarga de redirigir al login cuando alguien intente entrar sin credenciales.
¿Qué hace el middleware auth en Laravel? Verifica si el usuario está autenticado antes de ejecutar la ruta. Si no lo está, lo redirige automáticamente al formulario de inicio de sesión.
¿Qué rutas debes proteger en un sistema de Q&A?
No todas las rutas necesitan protección. Estas son las que sí:
- Formulario de creación de preguntas.
- Guardado en base de datos (store).
- Formulario de edición y actualización.
- Eliminación de registros.
- Envío de respuestas y comentarios.
La visualización pública sí permanece abierta, porque cualquier visitante debería poder leer las preguntas existentes.
¿Cómo mostrar botones según el estado de sesión?
Proteger las rutas no basta. Si el botón de eliminar sigue visible para un visitante, vas a generar fricción y confusión. La solución está en las directivas Blade @auth y @guest [3:00].
@guest muestra contenido solo a visitantes sin sesión, mientras que @auth lo muestra solo a usuarios autenticados. Con esto controlas el botón de inicio de sesión, el saludo personalizado y el botón de logout.
¿Cómo implementar el cierre de sesión?
El kit de inicio de Laravel ya trae un formulario de logout listo. Lo copias desde la vista del repositorio, lo pegas en tu menú y aplicas la lógica:
- Si el usuario inició sesión, muestra su nombre y el botón de cerrar sesión.
- Si es visitante, muestra el botón de inicio de sesión.
Esa coherencia visual evita que un usuario autenticado vea opciones que no le corresponden.
¿Cómo personalizar la redirección después del login?
Por defecto, el kit de inicio de Laravel redirige al panel administrativo (dashboard) tras iniciar sesión o registrarse. Para un proyecto público como un blog o sistema de preguntas, eso no tiene sentido.
Abre el controlador de autenticación, busca la línea de redirección al final del flujo (después de la validación) y cámbiala para que apunte a home. Haz lo mismo en el controlador de registro [5:30].
¿Dónde se cambia la redirección después del login en Laravel? En el controlador de autenticación del kit de inicio, al final del método donde se ejecuta el login. Reemplaza la ruta del dashboard por la ruta home.
¿Cómo obtener el ID del usuario autenticado dinámicamente?
Durante el desarrollo es común dejar hardcodeado un ID de prueba. En este caso era el usuario número 20. Eso debe volverse dinámico antes de producción.
Laravel ofrece el helper auth()->id() que devuelve el ID del usuario que inició sesión en ese momento. Reemplaza cada ocurrencia del 20 hardcodeado por este helper en:
- La creación de preguntas.
- El registro de comentarios.
- La lógica del botón de corazón o like.
- Cualquier acción que dependa del autor.
¿Qué hace auth()->id() en Laravel? Devuelve el ID numérico del usuario actualmente autenticado. Si nadie inició sesión, retorna null.
¿Por qué usar helpers en vez de IDs fijos?
Un ID fijo rompe la lógica multiusuario. Si dejas el 20, todos los registros se atribuyen al mismo usuario sin importar quién los cree. El helper garantiza que cada acción quede asociada al autor real.
¿Cómo ocultar acciones sensibles con Livewire y Blade?
El último ajuste va a nivel de componentes. Dentro del sistema de preguntas envuelves los botones de editar y eliminar con @auth. En el componente Livewire de comentarios haces lo mismo con el formulario de envío.
Para el botón de corazón hay un truco visual elegante: si el usuario está autenticado, muestra el ícono interactivo. Si no, muestra el ícono en formato gris que no responde al clic. Así el visitante ve que la función existe pero entiende que necesita iniciar sesión.
Para el formulario de respuesta aplica la misma lógica con un mensaje claro: "Inicia sesión para responder". Ese texto convierte la restricción en una invitación.
Habilidades y conceptos que dominaste
- Middleware auth [0:30]: capa de verificación que bloquea rutas a usuarios no autenticados.
- Directiva @guest [3:10]: muestra contenido exclusivo para visitantes sin sesión.
- Directiva @auth [3:50]: muestra contenido solo a usuarios autenticados.
- Helper auth()->id() [6:20]: obtiene dinámicamente el ID del usuario en sesión.
- Redirección personalizada [5:30]: control del flujo post login y post registro.
- Logout con formulario [4:10]: cierre de sesión seguro mediante POST.
- Control visual con Livewire [7:40]: ocultar botones según estado de autenticación en componentes reactivos.
Ahora replica esta funcionalidad en tu módulo de blog y cuéntanos en los comentarios cómo resolviste la protección de rutas en tu propio proyecto.