Notifiche
Libre WebUI mantiene per ogni utente una casella di notifiche permanente, così le attività del team, come menzioni, messaggi diretti, condivisioni, errori delle automazioni e promemoria del calendario, raggiungono le persone anche quando la pagina interessata è chiusa.
Casella delle notifiche
Le notifiche sono innanzitutto righe del database: titolo e corpo sono crittografati quando vengono archiviati, il limite è di 500 per utente (le più vecchie vengono eliminate) e una chiave sorgente facoltativa consente di deduplicarle, così pubblicazioni ripetute confluiscono in un'unica voce anziché riempire la campana di avvisi. La superficie RESTful permette di elencarle, contare quelle non lette, segnarne una o tutte come lette ed eliminarle.
La distribuzione in tempo reale usa il flusso di eventi permanente per utente notify:<userId> tramite GET /api/notifications/events (SSE). L'identità del flusso deriva dalla sessione autenticata, mai dall'input del client, e la casella SQL resta la fonte autorevole: un evento perso viene recuperato leggendo l'elenco, non riproducendo il flusso.
Eventi che producono notifiche
| Tipo | Quando viene prodotta |
|---|---|
channel-dm | Qualcuno ti invia un messaggio diretto |
channel-mention | Qualcuno ti @mentions in un canale o risponde al tuo messaggio |
channel-invite | Vieni aggiunto a un canale |
share | Qualcuno condivide una risorsa con te |
automation-failed | Una delle tue automazioni non riesce, salvo che abbia disattivato l'opzione |
calendar-reminder | Un evento con promemoria raggiunge l'orario previsto |
work-run-finished | Uno degli agenti Work che hai incaricato completa un'esecuzione |
work-run-attention | Un agente incaricato si ferma in attesa di input o incontra un errore |
work-takeover | Un agente Work ti chiede di assumere il controllo del suo schermo |
work-approval | Un'esecuzione Work attende che tu approvi un'azione con effetti collaterali |
system | Annunci a livello di istanza |
Le notifiche vengono sempre pubblicate soltanto per l'utente interessato; la menzione di un nome utente che non appartiene al canale non produce nulla.
Webhook in uscita
Gli amministratori possono registrare destinazioni webhook che ricevono gli eventi del team.
- Uscita protetta. Le destinazioni sono sottoposte agli stessi criteri dei server di strumenti: URL esatto, nessun reindirizzamento e nessun indirizzo privato o link-local, a meno che l'amministratore non inserisca esplicitamente un host in
TOOLS_PRIVATE_NETWORK_ALLOWLIST. I nomi host vengono risolti e controllati nuovamente a ogni distribuzione. - Firmati. Quando è configurato un segreto, ogni distribuzione include
X-Libre-Signature: sha256=<hmac>, calcolato sul corpo esatto. - Con dati rimossi. L'involucro contiene il tipo di evento e di notifica, il titolo, gli identificatori e i timestamp. Corpi delle notifiche, contenuti dei messaggi, prompt e documenti non lasciano mai l'istanza.
- Permanenti. Le distribuzioni vengono eseguite come processi permanenti con un numero limitato di tentativi; una risposta 5xx del destinatario viene ritentata, mentre una risposta 4xx è considerata il verdetto del destinatario e conclude il tentativo.
- Con ambito. Ogni destinazione si abbona a tipi di notifica specifici oppure a
*.
Notifiche push del browser
Impostazioni → Notifiche registra questo browser per Web Push, così menzioni, condivisioni, promemoria e attività completate raggiungono il dispositivo anche quando la scheda è chiusa. L'implementazione è standard e autonoma:
- VAPID (RFC 8292). Il server firma ogni distribuzione con una coppia di chiavi ES256, generata una volta e archiviata in forma crittografata oppure fissata tramite
VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY(VAPID_SUBJECTimposta il campo del contatto). Non sono coinvolti servizi o librerie push di terze parti, oltre all'endpoint push del fornitore del browser. - Payload crittografati (RFC 8291). Ogni messaggio viene crittografato con aes128gcm per le chiavi specifiche del dispositivo prima di lasciare l'istanza; il servizio push inoltra testo cifrato che non può leggere.
- Per dispositivo e associati alla sessione. Un abbonamento appartiene al browser che lo ha creato e alla sua sessione di autenticazione: la disconnessione della sessione (o l'opzione «disconnetti le altre sessioni») rimuove anche la registrazione push. Gli endpoint vengono archiviati in forma crittografata con un token di ricerca con chiave e devono essere destinazioni HTTPS pubbliche, applicando le stesse precauzioni per il traffico in uscita dei webhook.
- Permanenti. Le distribuzioni push vengono eseguite come processi permanenti con un numero limitato di tentativi; se il servizio push segnala che l'abbonamento non esiste più (404/410), viene rimosso.
- Il payload contiene il titolo della notifica, il corpo facoltativo, il tipo e il link di destinazione, con la stessa politica di rimozione dei dati della casella.
Le notifiche push richiedono l'app di produzione (il service worker viene registrato soltanto in tale ambiente) e un'origine sicura. La shell offline e la possibilità di installazione provengono dallo stesso service worker: il manifesto dell'app rende Libre WebUI installabile, quando si è offline la navigazione passa alla shell memorizzata nella cache e le risorse di build con hash vengono memorizzate in modo immutabile. Il traffico API non viene mai memorizzato nella cache.
Confini
- Le preferenze utente per tipo non sono ancora implementate; le automazioni rispettano la propria impostazione di notifica e l'uscita da un canale interrompe le relative notifiche.