SmartAuth 2.0.60: rotta di salute, installazione incompleta segnalata e conflitti di sincronizzazione resi affidabili

Una rotta di salute per le applicazioni mobili

Le applicazioni SmartMaker verificano regolarmente che il server risponda prima di inviare ciò che hanno registrato offline. In precedenza, disponevano solo di rotte protette, che rispondevano con un rifiuto senza token: il server poteva sembrare irraggiungibile mentre funzionava.

GET e HEAD su api.php/health rispondono ora con 204, senza corpo e senza token, senza query al database né riga nel registro delle richieste di SmartAuth: la rotta può essere chiamata ogni minuto. Più in generale, una richiesta HEAD viene gestita dalla rotta GET dello stesso percorso, con lo stesso controllo di accesso, e un percorso chiamato con un metodo che non accetta risponde con 405 insieme all'elenco dei metodi accettati.

Un'installazione incompleta segnalata chiaramente

Dolibarr attiva un modulo prima delle sue dipendenze e lo lascia attivato quando una di esse fallisce. Un modulo SmartMaker poteva quindi essere in esecuzione mentre SmartAuth non era attivato, e la sua applicazione falliva al collegamento su una tabella assente. L'API risponde ora con 503 indicando che SmartAuth non è attivato, e la causa viene registrata nel log.

Conflitti di sincronizzazione associati al tipo corretto

Un modulo può dichiarare i propri tipi di oggetti sincronizzati, eventualmente su una tabella già utilizzata da un tipo di SmartAuth. Un conflitto registrava solo la sua tabella: la risoluzione poteva applicare le regole di un altro tipo, e l'applicazione doveva indovinare il tipo da sola. Ogni conflitto registra ora il suo tipo, restituito da GET sync/conflicts (object_type) e utilizzato per la risoluzione. La riattivazione del modulo aggiunge la colonna; senza di essa, il comportamento precedente viene mantenuto.