Estado, cookies y sesiones

Un teatro ficticio recuerda tu inicio de sesión al pasar de elegir asientos a consultar reservas. Las solicitudes HTTP no llevan una memoria inherente de solicitudes anteriores. La aplicación construye esa continuidad mediante identificadores y estado almacenado. Resulta útil, pero crea un ciclo de vida que debe gestionarse de forma deliberada.

Una cookie guarda un valor y reglas de envío

Una cookie es un valor almacenado por el navegador junto con reglas que determinan cuándo se envía. El servidor puede establecerla en una respuesta; los scripts también pueden crear ciertas cookies. Puede recordar idioma, preferencias o un identificador de sesión. Su presencia no significa necesariamente que alguien haya iniciado sesión.

En un diseño habitual, el teatro emite un identificador impredecible después de autenticar. El navegador lo guarda en una cookie. En solicitudes posteriores que cumplen las reglas, lo envía y el servicio busca un registro que relaciona la visita con una cuenta y una política de vencimiento. Ese identificador debe tratarse como una credencial aunque no sea la contraseña personal.

La sesión es una relación

Un comprobante de guardarropa sirve como comparación: su número conecta a quien lo presenta con un registro. Tiene un límite: un identificador digital se puede copiar y el servicio puede aplicar comprobaciones adicionales. Algunas aplicaciones usan tokens firmados en lugar de consultar un identificador opaco. La firma aporta integridad según sus reglas de verificación; no significa automáticamente cifrado, vigencia o revocación sencilla.

El estado de la aplicación incluye más que la sesión. Carrito, reserva y pago pueden estar en registros separados con duraciones diferentes. Vencer una sesión no elimina necesariamente una reserva terminada. El vencimiento de una cookie tampoco equivale a la decisión del servicio de terminar la sesión.

PrediceEl teatro acepta la sesión vigente de Maya. ¿Significa que puede cancelar todas las reservas de la base de datos?

No. La sesión establece un contexto autenticado. El servicio todavía debe autorizar la acción concreta sobre la reserva concreta. Identidad, vigencia y permisos de objetos son preguntas separadas.

Cada control protege un límite diferente

Secure restringe el envío de la cookie a conexiones seguras en un despliegue web ordinario. HttpOnly impide acceder mediante las API de cookies para scripts; no evita que el navegador adjunte la cookie a solicitudes válidas. SameSite limita ciertos envíos entre sitios según su configuración y la solicitud. Ninguno de estos atributos proporciona por sí solo toda la protección necesaria.

Dominio y ruta también influyen en el envío. Una ruta no constituye una barrera sólida entre aplicaciones que desconfían unas de otras. Conviene limitar el alcance, proteger el canal y dejar que el servidor aplique las decisiones de acceso.

Termina la relación de forma clara

Con sesiones del lado del servidor, cerrar sesión debe invalidarla además de borrar el valor del navegador. El vencimiento por inactividad y el absoluto miden duraciones diferentes. Tras un cambio sensible de identidad, rotar el identificador evita conservar una relación anterior. Los mensajes deben explicar cuándo hay que autenticarse de nuevo sin afirmar que desaparecieron todos los datos guardados de la cuenta.