Proteger rutas en una aplicación PHP es uno de los pasos más importantes cuando quieres que solo el dueño de la página acceda a ciertas acciones. Aquí aprendes cómo crear tu primer middleware en PHP para interceptar peticiones, validar autenticación y redirigir al login cuando no exista sesión activa. Es contenido pensado para quienes ya manejan rutas y controladores y quieren sumar una capa de seguridad real.

Por qué se llama middleware y qué hace en el flujo de una petición

El nombre lo dice todo: actúa en el medio. Entre la petición del usuario y la respuesta del sistema hay un espacio donde puedes detener, validar o redirigir. Ese espacio es el middleware.

En un flujo normal, llega una request, se dispara el método del controlador y se imprime la ruta. Con middleware, ese flujo se interrumpe para preguntar algo tan simple como: ¿estás autenticado? Si la respuesta es sí, continúa; si es no, te mando al login.

¿Qué es un middleware? Es una capa intermedia que se ejecuta entre la petición del usuario y el controlador. Sirve para validar permisos, autenticación o cualquier regla antes de procesar la acción.

Cómo crear la estructura del middleware authenticated

Lo primero es crear una carpeta nueva donde vivirán estos interceptores. Dentro creas tu primera clase, y le pones un nombre en pasado, como authenticated, porque la pregunta que resuelve es: ¿ya estás autenticado?.

Defines el namespace, declaras la clase y trabajas con un método mágico, un concepto que viene desde fundamentos de PHP. Ese método se dispara automáticamente cuando instancias el objeto, lo que hace al middleware muy limpio de invocar.

Dentro del método, la lógica es directa:

• Verificar si existe el usuario a nivel de sesión.
• Si no existe, hacer un redirect usando un helper ya creado.
• Enviar al usuario a la vista de login.
• Si existe, dejar que la petición siga su curso.

Cómo registrar el middleware en las rutas protegidas

Aquí viene lo interesante. Las rutas que crean, guardan, editan, actualizan o eliminan no pueden estar abiertas al público. Solo las rutas de lectura pública quedan libres.

Para lograrlo, las rutas reciben ahora un tercer parámetro opcional: el middleware. La estructura del arreglo cambia y queda con tres llaves: arrangement, action y middleware.

Cómo se ajusta el sistema de rutas para aceptar middleware

En el archivo de rutas web, el valor por defecto del middleware se inicializa en null. Así mantienes flexibilidad: las rutas públicas siguen funcionando sin tocar nada, y solo las protegidas declaran su middleware.

Luego, en el router, después de resolver la action, se evalúa con un if si existe el middleware asociado. Si existe, se instancia con new y eso dispara el método mágico que hace la validación.

php if ($middleware) { new $middleware(); }

Este patrón deja el código más legible y evita repetir validaciones en cada controlador.

¿Para qué sirve proteger rutas con middleware? Para que solo usuarios autenticados accedan a acciones sensibles como crear, editar o eliminar, mientras las vistas públicas siguen disponibles para cualquiera.

Cómo se comporta el sistema después de aplicar la protección

Al refrescar la aplicación, las rutas públicas como home, about y projects siguen abiertas. Pero al intentar entrar a registrarse o a una vista protegida, el sistema responde con Sign in, porque el middleware interceptó la petición.

La vista de login todavía no existe en este punto, y ese es justamente el siguiente paso del desarrollo. Lo importante es que la interceptación ya funciona: cada request pasa por el filtro antes de llegar al controlador.

Qué conceptos técnicos están en juego aquí

• Middleware: capa intermedia entre request y controlador que valida condiciones antes de ejecutar la acción.
• Método mágico: método especial de PHP que se ejecuta automáticamente al instanciar la clase, ideal para disparar la lógica de validación sin llamadas extra.
• Namespace: organización lógica de clases para evitar colisiones de nombres y mantener el proyecto ordenado.
• Helper de redirect: función auxiliar reutilizable que envía al usuario a otra vista, en este caso al login.
• Sesión de usuario: mecanismo que indica si alguien está autenticado; si no existe, el middleware corta el flujo.
• Array de ruta con action y middleware: estructura que permite asociar opcionalmente un interceptor a cada ruta sin romper las que no lo necesitan.

Una alternativa más rápida queda comentada en el código, porque siempre conviene mostrar dos caminos: el paso a paso para entender, y la versión corta para producir.

El reto que sigue es claro: aplica esta misma protección al módulo del blog y observa cómo cambia el comportamiento de tus rutas. ¿Cómo organizarías tú los middlewares si tuvieras que validar también roles de usuario? Cuéntalo en los comentarios.