| Tabla de contenidos |
|---|
...
| Info |
|---|
|
Las aplicaciones FundewebJS funcionan con un enfoque basado en servicios lo que implica que las comunicaciones son sin sesión. No obstante en ocasiones nuestra aplicación debe guardar el estado debido a: hace una navegación a una aplicación externa y luego se vuelve a ésta, es un wizard donde los cambios sólo se persisten al final, etc.
...
En consecuencia no se debe almacenar guardar en Vuex ningún dato que contenga información personal o cualquiera otra que , procesada desde el navegador pueda suponer un problema de seguridad y/o privacidad. En cambio, para la comunicación entre componentes se puede guardar la información que sea necesaria para que la aplicación funcione correctamente.
Para solventar el problema de tener que gestionar una sesión sin exponer datos sensibles se ha desarrollado un mecanismo que permitirá guardar en base de datos un JSON con la información de la sesión en curso que, combinado con un ID de sesión que se podrá almacenar en VUEX, nos permitirá simular una sesión web sin estar expuestos a una posible vulneración de la privacidad de los datos.
...
Al mismo tiempo se deberá crear un JOB de base de datos que limpie esta tabla de las sesiones expiradas. (El procedimiento para borrar los datos podéis descargarlo en este enlace sólo quedaría configurar el job para que se ejecute cada 30 minutos que es la duración recomendaba de una sesión si no tiene uso).
Detalle del ciclo de vida
...
El frontend será el encargado de generar un ID de sesión cuando un usuario haga login y añadirlo en la cabecera UMU-User-SessionID de toda las peticiones a los diferentes backends junto con el token OAuth.
Inicio de la sesión
La primera vez que el usuario acceda a la aplicación, si ésta requiere de sesión, la creará en el endpoint que reciba la acción de inicio del proceso del usuario. Este endpoint se deberá encargar de: obtener el identificador del usuario que contiene el token OAuth ya validado y el identificador de sesión que vendrá como cabecera de la petición. Una ver obtenidos dichos campos almacenará en la tabla de sesiones todos los datos requeridos y ejecutará la lógica de negocio restante.
...
Una implementación que podemos hacer en nuestros servicios que inician un proceso es comprobar si existe una sesión en base de datos y notificar al usuario que ya tiene una sesión completa hasta el paso X, preguntando si quiere continuarla o empezar una nueva. Esta lógica puede ser útil para tener en cuenta los casos en que se produzca un fallo sin que se pudiera cerrar la sesión, por ejemplo que el usuario se quede sin conexión a mitad de un proceso, reinicie el equipo y vuelva a probar.
Librería de gestión de sesiones
Disponemos de una librería con los métodos necesarios para escribir, leer y borrar sesiones, documentado en esta guía: Librería de gestión de sesiones