SmartAuth 2.0.60: gezondheidsroute, onvolledige installatie gemeld en synchronisatieconflicten betrouwbaarder gemaakt

Een gezondheidsroute voor mobiele applicaties

SmartMaker-applicaties controleren regelmatig of de server reageert voordat they verzenden wat ze offline hebben opgeslagen. Voorheen hadden ze hiervoor alleen beveiligde routes, die een weigering gaven zonder token: de server kon onbereikbaar lijken terwijl hij functioneerde.

GET en HEAD op api.php/health antwoorden nu met 204, zonder body en zonder token, zonder databasequery of regel in het aanvragenlogboek van SmartAuth: de route kan elke minuut worden aangeroepen. Meer algemeen wordt een HEAD-verzoek afgehandeld door de GET-route van hetzelfde pad, met dezelfde toegangscontrole, en een pad dat wordt aangeroepen met een methode die het niet accepteert, antwoordt met 405 en de lijst van geaccepteerde methoden.

Een onvolledige installatie duidelijk gemeld

Dolibarr activeert een module voordat zijn afhankelijkheden zijn geactiveerd en laat hem geactiveerd wanneer een daarvan faalt. Een SmartMaker-module kon dus draaien terwijl SmartAuth niet was geactiveerd, en zijn applicatie faalde bij de verbinding op een ontbrekende tabel. De API antwoordt nu met 503 en geeft aan dat SmartAuth niet is geactiveerd, en de oorzaak wordt gelogd.

Synchronisatieconflicten gekoppeld aan het juiste type

Een module kan zijn eigen types van gesynchroniseerde objecten declareren, eventueel op een tabel die al wordt gebruikt door een type van SmartAuth. Een conflict registreerde alleen zijn tabel: de oplossing kon de regels van een ander type toepassen, en de applicatie moest zelf het type raden. Elk conflict registreert nu zijn type, teruggegeven door GET sync/conflicts (object_type) en gebruikt voor de oplossing. Het opnieuw activeren van de module voegt de kolom toe; zonder deze wordt het vorige gedrag behouden.