En aquellos tiempos, Tim Berners-Lee inventó el HTTP, y lo hizo sin sesión, y vio que aquello era bueno.

Sin embargo, en la actualidad, casi todas las aplicaciones web usan de la sesión HTTP. ¿Qué es lo que ha pasado?.

Aunque realmente no hay nada malo en usar sesión ¿no? … o tal vez sí.

Con el modelo clásico de la web, en el que el navegador hace una petición al servidor, y con la respuesta de éste reemplaza la página actual con la que le envía el servidor, teníamos un problema:

Si la funcionalidad que queremos implica tener varias pantallas ¿dónde podríamos guardar la información que el usuario introduce en las páginas anteriores? También cualquier otra información que queremos tener disponible siempre, sin volver a preguntar al usuario, como su nombre y apellidos, domicilio, etc.

Si no podemos guardarla en el navegador, porque las páginas se cargan y se descargan, entonces las podemos guardar en el servidor. ¿Y cómo hacemos esto esto si HTTP es sin estado? Pues nos inventamos una cosa, que es la cookie de sesión, que guarde un identificador único para esta sesión dentro del servidor. Como cookie que es viajará al servidor en cada petición y éste y sabrá encontrar la información de sesión para ese usuario a partir de este identificador.

Y a partir de aquí, todo se ha ido complicando más y más. ¿que hacemos cuando hay muchos usuarios y la sesión tiene bastante información? pues que la necesidad de memoria del servidor aumente proporcioalmente a este número de usuarios.

Ahora bien, si tenemos un sistema de alta disponiblidad con varios servidores (nodos) que dan servicio para la misma apliación. ¿qué pasa si un servidor se cae? pues que la sesión de los usuarios que estuviesen en ese momento en la memoria se destruirían sin más. ¿cómo solucioamos esto? pues estableciendo un complejo mecanismo de copia de las sesiones de un servidor a otro. De tal manera que si se cae, prestará servicio al usuario otro servidor con sus datos de sesión copiados.

¿Y cómo pasamos el contenido de la sesión de un servidor a otro? pues necesitamos tener un medio para hacerlo, puede ser fichero o base de datos. Ahora bien, cómo hacemos para volcar el contenido de la memoria en disco o en base de datos. Mediante la serialización de la memoria. En Java por ejemplo, es obligatorio que todos los objetos que se guarden en sesión implementen el interfaz Serializable. Si por lo que sea, encuentra un objeto que no lo sea, la serialización no puede hacerse. Si ocurre lo peor, y se cae el nodo, donde está la sesión del usuario, entonces no puede darse servicio.

Recapitulando, el uso de la sesión en el servidor, tiene tres grandes problemas:

  1.  necesita un espacio de memoria directamente proporcional al número de usuarios que están usando la aplicación
  2.  es necesario un mecanismo de serialización de la memoria. Esto implica consumo de recursos para mantener la sesión replicada en todos los nodos.
  3.  a consecuencia de lo anterior, con una sesión web de este tipo, la aplicación no será altamente escalable.

¿qué alternativas hay?

Las modernas aplicaciones web, con uso intensivo de javascript y CSS, dentro del estándar HTML5 pueden perfectamente manejar en el navegador la vista, el controlador y parte del modelo (los objetos que contienen la información de negocio). Y pueden perfectamente basarse en servicios REST stateless en el servidor para intercambiar estos objetos del modelo con el backend, en definitiva con los servicios de negocio y al final en el repositorio de datos.

Peligros

Todo lo que implica el uso de tecnologías en el cliente (en el navegador) tiene un riesgo desde el punto de vista de la seguridad. Al fin y al cabo el código de la aplicación de interfaz de usuario se ejecuta en el lado del cliente (bajo su control) no desde el nuestro. Y un usuario, digamos que seducido por el lado oscuro, podría intentar hackear la aplicación con no muy buenas intenciones.

Evidentemente, en este caso, tendremos que securizar los servicios del servidor, y por supuesto hacer todas las validaciones de formato para evitar los ataques tipo SQL injection, XSS, CSFR, y demás ralea.

Control del flujo

Otro posible motivo para tener sesión en el servidor, es el control del flujo de pantallas. Si necesitamos ejecutar un flujo determinado de pantallas, con un cierto orden, siguiendo un workflow, querremos asegurarnos de que el usuario siga una cierta secuencia de pantallas.

Personalmente, no creo que esto sea necesario al fin y al cabo. Desde siempre, SOA proporciona servicios sin estado, con todo la lógica de negocio de la aplicación. Y para estos servicios, poco les importa la secuencia de pantallas que ha seguido el usuario.

Conclusión

En una aplicación web moderna, donde la vista y el control residen en el navegador, no veo razón para mantener la arquitectura clásica de guardar la sesión el servidor. Son muchos los problemas de rendimiento y escalabilidad que plantea tener el implementar esto.

¿Se os ocurre alguna razón para mantener la sesión en el servidor?

Comparte esta entrada:
Share