SmartAuth 2.0.56: sesiones móviles preservadas e instalación más robusta

Las aplicaciones móviles permanecen conectadas

Un token de refresco solo sirve una vez: si se presenta dos veces, SmartAuth lo interpreta como un robo y revoca toda la familia de tokens del dispositivo. Hasta ahora, una base de datos momentáneamente no disponible en el momento de ese control producía el mismo efecto, y el usuario se encontraba desconectado de su aplicación sin haber hecho nada.

SmartAuth distingue ahora las dos situaciones. Una verdadera reutilización del token sigue tratándose como un ataque. Un fallo de almacenamiento responde con un error temporal (HTTP 503): la sesión se conserva y la aplicación vuelve a intentarlo por sí misma.

Una instalación que no deja nada a medias

La activación del módulo comprueba que cada una de sus tablas se haya creado. Si falta alguna, la activación se rechaza y el motivo se registra, en lugar de terminar con un módulo activo que falla más tarde en la primera consulta.

Varias tablas compartían los mismos nombres de índice. Bajo PostgreSQL, donde un nombre de índice es único para toda la base de datos, solo se creaba el primero y las demás columnas quedaban sin índice. Cada índice lleva ahora el nombre de su tabla. En una instalación MySQL existente, los antiguos índices se eliminan al reactivar el módulo, una vez los nuevos estén en su lugar.

Respuestas a los correos vinculadas al expediente correcto

Los correos enviados por SmartAuth (restablecimiento de contraseña, registro, alerta de nueva conexión, confirmación de dirección) llevan ahora el identificador de seguimiento de Dolibarr de su destinatario. Con el colector de correos de Dolibarr, una respuesta a uno de estos correos se vincula al usuario, al miembro o al tercero correspondiente.