SmartAuth 2.0.56: mobile sessions preserved and more robust installation

Mobile applications stay connected

A refresh token is used only once: if it is presented twice, SmartAuth treats this as theft and revokes the device's entire token family. Until now, a database momentarily unavailable at the time of this check produced the same effect, and the user found themselves disconnected from their application without having done anything.

SmartAuth now distinguishes between the two situations. A genuine reuse of the token is still treated as an attack. A storage failure returns a temporary error (HTTP 503): the session is kept and the application retries on its own.

An installation that leaves nothing half done

Module activation checks that each of its tables has indeed been created. If one is missing, activation is refused and the reason is logged, instead of resulting in an active module that fails later on the first request.

Several tables shared the same index names. Under PostgreSQL, where an index name is unique across the whole database, only the first was created and the other columns remained without an index. Each index now bears the name of its table. On an existing MySQL installation, the old indexes are removed when the module is reactivated, once the new ones are in place.

Email replies attached to the right record

Emails sent by SmartAuth (password reset, registration, new login alert, address confirmation) now carry the Dolibarr tracking identifier of their recipient. With Dolibarr's email collector, a reply to one of these emails is attached to the user, the member or the third party concerned.