SmartAuth 2.0.56 : sessions mobiles préservées et installation plus robuste

Les applications mobiles restent connectées

Un jeton de rafraîchissement ne sert qu'une fois : s'il est présenté deux fois, SmartAuth y voit un vol et révoque toute la famille de jetons de l'appareil. Jusqu'ici, une base de données momentanément indisponible au moment de ce contrôle produisait le même effet, et l'utilisateur se retrouvait déconnecté de son application sans rien avoir fait.

SmartAuth distingue maintenant les deux situations. Une vraie réutilisation du jeton est toujours traitée comme une attaque. Une panne de stockage répond une erreur temporaire (HTTP 503) : la session est conservée et l'application réessaie d'elle-même.

Une installation qui ne laisse rien à moitié

L'activation du module vérifie que chacune de ses tables a bien été créée. Si l'une manque, l'activation est refusée et la raison est journalisée, au lieu d'aboutir à un module actif qui échoue plus tard à la première requête.

Plusieurs tables partageaient les mêmes noms d'index. Sous PostgreSQL, où un nom d'index est unique pour toute la base, seul le premier était créé et les autres colonnes restaient sans index. Chaque index porte désormais le nom de sa table. Sur une installation MySQL existante, les anciens index sont retirés à la réactivation du module, une fois les nouveaux en place.

Des réponses aux mails rattachées au bon dossier

Les mails envoyés par SmartAuth (réinitialisation de mot de passe, inscription, alerte de nouvelle connexion, confirmation d'adresse) portent désormais l'identifiant de suivi Dolibarr de leur destinataire. Avec le collecteur d'e-mails de Dolibarr, une réponse à l'un de ces mails est rattachée à l'utilisateur, à l'adhérent ou au tiers concerné.