SmartAuth 2.0.60: Health-Check-Route, unvollständige Installation gemeldet und Synchronisationskonflikte zuverlässiger behandelt

Eine Health-Check-Route für mobile Anwendungen

Die SmartMaker-Anwendungen prüfen regelmäßig, ob der Server antwortet, bevor sie das übermitteln, was sie offline gespeichert haben. Dafür standen ihnen nur geschützte Routen zur Verfügung, die eine Ablehnung ohne Token zurückgaben: der Server konnte unerreichbar erscheinen, obwohl er funktionierte.

GET und HEAD auf api.php/health antworten nun mit 204, ohne Inhalt und ohne Token, ohne Datenbankabfrage oder Eintrag im Anforderungsprotokoll von SmartAuth: Die Route kann jede Minute aufgerufen werden. Allgemeiner wird eine HEAD-Anfrage von der GET-Route desselben Pfads bedient, mit derselben Zugriffskontrolle, und ein Pfad, der mit einer nicht akzeptierten Methode aufgerufen wird, antwortet mit 405 und der Liste der akzeptierten Methoden.

Eine unvollständige Installation klar signalisiert

Dolibarr aktiviert ein Modul vor seinen Abhängigkeiten und lässt es aktiviert, wenn eine davon fehlschlägt. Ein SmartMaker-Modul konnte daher laufen, während SmartAuth nicht aktiviert war, und seine Anwendung scheiterte beim Verbindungs- aufbau an einer fehlenden Tabelle. Die API antwortet nun mit 503 und zeigt an, dass SmartAuth nicht aktiviert ist, und die Ursache wird protokolliert.

Synchronisationskonflikte dem richtigen Typ zugeordnet

Ein Modul kann eigene Typen synchronisierter Objekte deklarieren, möglicherweise auf einer Tabelle, die bereits von einem SmartAuth-Typ verwendet wird. Ein Konflikt speicherte nur seine Tabelle: Die Auflösung konnte die Regeln eines anderen Typs anwenden, und die Anwendung musste den Typ selbst erraten. Jeder Konflikt speichert nun seinen Typ, der von GET sync/conflicts (object_type) zurückgegeben und für die Auflösung verwendet wird. Die Reaktivierung des Moduls fügt die Spalte hinzu; ohne sie bleibt das bisherige Verhalten erhalten.