Historial de página

...

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 que navega : 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.

...

A la hora de gestionar una sesión deberemos tener en cuenta en nuestra aplicación cuándo debemos crearla, cuándo debemos usarla y cuándo debemos cargarla. El grafo que se muestra a continuación esquematiza el ciclo de vida que deben implementar los endpoints que requieran hacer uso de sesiones.

Image RemovedImage Added

Estructura de base de datos

Cada aplicación de servicios en api.um.es tendrá que tener su propia tabla de sesiones que contendrá los siguientes campos:

• ID: Será el valor del campo JTI que se encuentra en el token OAuth del usuario. Este valor es único por usuario por lo tanto identifica a la vez al usuario y a la sesión.un valor único generado por el frontend que identificará la sesión en curso.
• IDENTIFICADOR_USUARIO: Será el identificador del usuario logueado que viene en el token OAuth.
• FECHA_EXPIRACION: El timestamp que indica la fecha en la cual la sesión caducaráFECHA_EXPIRACION: Cuando expirará el token y, a su vez, la sesión del usuario. El tiempo de vida es fijo para el token OAuth y la sesión de usuario no podrá durar más que el token.
• CONTENIDO_SESION: Un JSON con toda la información necesaria para restaurar la sesión.

Para crear el esquema de base de datos descarga la plantilla de gestión de sesiones y sustituye [MIESQUEMA] por el esquema de base de datos donde la estés creando.

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

Gestión del identificador de sesión

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á en cargar encargar de: obtener los campos jti y exp del el identificador del usuario que contiene el token OAuth ya validado , almacenar 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 responder a la petición del frontend.Desde el punto de vista del frontend la creación de sesiones, al basarse en el token OAuth, es totalmente transparente por lo que no afectará a las llamadas que se realicenejecutará la lógica de negocio restante.

Gestión de una petición que requiera sesión

El frontend llamará al servicio que requiera del backend pasándole el token OAuth, el identificador de sesión y los parámetros que requiera propios de dicha llamada. Una vez recibida esa petición en el endpoint y validado el token, se extraerá el campo jti a partir del cual se recuperará identificador de usuario que, junto con el identificador de sesión, se usará para recuperar la sesión del usuario en curso. En la lógica del endpoint se debe contemplar de manera explicita la recuperación de la sesión.

Una vez recuperado el JSON con los datos, este podrá ser mapeado a objetos java (si se precisa y actuar en consecuencia. ) y ejecutar la lógica de negocio implicada en el servicio.

Tras realizar todas las acciones pertinentes, el endpoint deberá actualizar el estado de la sesión y devolver el flujo al frontend.

Cierre de sesión

La sesión podrá cerrarse de dos maneras: de manera explícita desde el frontend, de manera implícita por que caduque. Como POSE es un portal distribuido compuesto por varias aplicaciones, podemos delegar el cierre de sesión al propio portal el cual eliminará el ID de sesión para el usuario en curso, o bien tener un cerrar sesión explícito en el último paso de nuestras aplicaciones de manera que, para nuestra aplicación, se borre de la tabla la sesión en curso porque hemos completado ya el proceso (por ejemplo en el último paso de un wizard).

Es importante cerrar la sesión cuando consideremos que el flujo que ha seguido el usuario por la aplicación ha terminado ya que de lo contrario al volver a ejecutar el servicio se cargará la última sesión guardada.

El cierre de sesión lo gestionaremos mediante eventos para que no interfiera con la respuesta al frontend. El servicio lanzará un evento indicando qué sesión hay que cerrar y otro método (que estará escuchando ese tipo de eventos) se encargará de borrar el registro de base de datos.

Recuperar sesiones en pasos intermedios

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 al estado que precise