Autenticazione

Due modalità, entrambe accettate dallo stesso middleware:

Cookie di sessione (browser)

POST /api/v1/auth/login con { "email": "...", "password": "..." } imposta un cookie chiamato illusiondb_session, valido per 7 giorni. POST /api/v1/auth/logout lo elimina lato server.

Token API (script, client esterni)

Un token si crea in Impostazioni → Il mio account: POST /api/v1/auth/tokens con { "name": "..." } – la risposta contiene il valore grezzo del token esattamente una volta. In seguito va inviato come:

Authorization: Bearer <il-tuo-token>

Il token stesso è un semplice valore casuale (codificato Base64-URL) – nessun prefisso fisso. Un token si revoca tramite DELETE /api/v1/auth/tokens/{id}.

In alternativa, per i casi senza controllo diretto sugli header (ad es. un <img src="..."> verso un allegato, un’esportazione CSV linkata direttamente): lo stesso token come parametro di query ?token=... (oppure &token=... se esiste già una query string):

GET /api/v1/tables/{tableId}/records/{pk}/attachments/{columnId}/{fileId}?token=<il-tuo-token>

Se è impostato anche un header Authorization, vince l’header. Avviso di sicurezza: un token nell’URL può finire nei log del server/proxy, nella cronologia del browser e negli header Referer di richieste successive – dove possibile continua a usare l’header Authorization, riservando la variante in query solo a casi come immagini incorporate o link diretti.

Endpoint pubblici

Raggiungibili senza alcuna autenticazione: POST /auth/login, GET /auth/setup-status, POST /auth/setup (configurazione al primo avvio), GET /healthz, GET /version. Funzionano anch’essi al di fuori del middleware normale gli endpoint del generatore di documenti e gli endpoint personalizzati contrassegnati come pubblici – questi decidono da soli, a ogni chiamata, se è necessaria l’autenticazione.