44 lines
2.3 KiB
Markdown
44 lines
2.3 KiB
Markdown
 
|
# DD-026 — Il testo della notifica viaggia dentro la push
|
||
|
|
|
||
|
|
**Stato:** accettata · **Data:** settembre 2026
|
||
|
|
|
||
|
|
**Contesto**
|
||
|
|
Le push partivano senza payload: il service worker, appena svegliato, chiedeva a
|
||
|
|
`/api/public/push-messaggio` che cosa mostrare. Ad app aperta funzionava; ad app chiusa e
|
||
|
|
telefono bloccato non arrivava niente. È lo scenario per cui il browser dà al worker pochi
|
||
|
|
secondi di vita: una fetch verso un endpoint che interroga Supabase è esattamente ciò che non
|
||
|
|
riesce a chiudersi in tempo, e senza `showNotification` non compare nulla. `Urgency: high` e
|
||
|
|
un timeout di 3 secondi sul recupero del testo avevano attenuato il sintomo, non la causa.
|
||
|
|
|
||
|
|
**Decisione**
|
||
|
|
Titolo e testo viaggiano cifrati nel corpo della push (`aes128gcm`, RFC 8188/8291) con le
|
||
|
|
chiavi `p256dh` e `auth` già salvate in `push_subscriptions`. Il service worker legge
|
||
|
|
`event.data.json()` e mostra la notifica: zero rete, zero attesa.
|
||
|
|
|
||
|
|
Cadono di conseguenza la route `push-messaggio`, la coda `promemoria_push` (con la sua
|
||
|
|
scadenza a 12 ore), `messaggioPalloniOggi()` e il timeout nel service worker: tutti pezzi che
|
||
|
|
esistevano solo per rimediare al payload vuoto. Tutti e tre i mittenti
|
||
|
|
(`apri-sondaggio`, `sollecita-presenze`, `promemoria-palloni`) avevano già il testo pronto
|
||
|
|
prima di inviare.
|
||
|
|
|
||
|
|
**Alternative scartate**
|
||
|
|
|
||
|
|
- Usare la libreria `web-push` → dipende da `node:crypto`, e il build nitro ha come target
|
||
|
|
Cloudflare. La cifratura sta in ~40 righe di Web Crypto, già disponibile ovunque.
|
||
|
|
- Allungare ancora il timeout della fetch → allunga anche il tempo in cui il worker può
|
||
|
|
morire prima di mostrare qualcosa. Il problema era la fetch, non la sua durata.
|
||
|
|
|
||
|
|
**Conseguenze**
|
||
|
|
|
||
|
|
- La notifica non dipende più dalla rete al momento del risveglio, e nemmeno da una funzione
|
||
|
|
serverless che risponda in fretta a freddo.
|
||
|
|
- Sparisce l'unico punto in cui chiunque conoscesse un endpoint push poteva leggere il
|
||
|
|
messaggio destinato a quel dispositivo.
|
||
|
|
- Il payload sta sotto i 4 KB: i testi attuali sono ampiamente dentro, ma un messaggio molto
|
||
|
|
lungo andrebbe accorciato.
|
||
|
|
- La tabella `promemoria_push` resta nel database, ora inutilizzata: va rimossa con una
|
||
|
|
migrazione quando si tocca lo schema.
|
||
|
|
|
||
|
|
**Riesame**
|
||
|
|
Se servisse mandare payload più grandi del limite del protocollo, o se un servizio push
|
||
|
|
smettesse di accettare corpi cifrati (nessuno lo fa: è lo standard).
|