Chiede le credenziali alle route che avvisano tutta la squadra (DD-024).

Le route in src/routes/api/public/ girano con la service role e saltano la RLS,
quindi DD-023 non le copre. Nessuna faceva un controllo di accesso: cercando
"authorization" in quella cartella l'unico header era lo User-Agent con cui
csi.ts chiama il portale CSI. Chiunque conoscesse l'URL poteva far suonare i
telefoni della squadra, e promemoria-palloni accetta perfino una POST con il
corpo vuoto.

La difesa apparente delle altre due — serve un id evento valido — non è una
difesa: l'id è "e" più il timestamp in base 36, compare negli URL che la squadra
si scambia ed è elencabile da qualsiasi utente loggato.

auth-route.server.ts porta i due controlli, diversi perché i chiamanti sono
diversi. apri-sondaggio e sollecita-presenze usano richiediAdmin: token della
sessione verificato con auth.getUser, poi ruolo admin da user_roles, la stessa
fonte di ruoli.ts. Il controllo precede la validazione dell'input, così la
risposta non rivela nemmeno se un evento esiste. promemoria-palloni usa
richiediSegreto, perché la chiama un cron che una sessione non ce l'ha: se
CRON_SEGRETO non è configurata la route resta chiusa con 503, perché una porta
che si riapre da sola quando manca una variabile non se ne accorge nessuno.

csi, push-config, push-subscribe e push-messaggio restano aperte: le chiamano il
browser prima del login e il service worker, dove qualsiasi segreto finirebbe
nel bundle.

Lato client i due pulsanti admin mandano il token con intestazioniAutenticate(),
letto al momento della chiamata e non da uno stato React.

permessi-route.test.ts copre il giro intero — nessun token, giocatore, admin —
avviando il server di sviluppo puntato al database locale, perché servono utenti
veri. Il controllo positivo è il 404: l'admin supera l'accesso e arriva alla
validazione. In api.test.ts restano i rifiuti che non richiedono un utente e
sparisce la verifica della validazione di sollecita-presenze, che ora sta dietro
all'accesso.

I limiti noti di palloni.md sono aggiornati: il secret che il piano originale
prevedeva ora c'è. Resta vero che nessun cron chiama la route, quindi il
promemoria quotidiano non parte da solo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/DESIGN_DECISIONS.md

@@ -38,6 +38,8 @@ Serve a rispondere a domande del tipo:
 | [DD-020](#dd-020--una-funzione-modificata-senza-test-non-è-finita)                | Test obbligatori e verdi              |
 | [DD-021](#dd-021--molle-interrompibili-al-posto-delle-animazioni-a-durata-fissa)  | Molle interrompibili con motion       |
 | [DD-022](#dd-022--lapp-è-solo-chiara)                                             | App solo chiara                       |
+| [DD-023](#dd-023--ogni-scrittura-è-limitata-a-chi-la-fa)                          | Scritture limitate per ruolo          |
+| [DD-024](#dd-024--le-route-che-avvisano-la-squadra-chiedono-le-credenziali)       | Route di notifica autenticate         |
 
 **In valutazione**
 
@@ -808,3 +810,64 @@ all'account (`benvenuto.tsx`), e senza slot non si entra.
 Se l'anonimato delle pagelle deve diventare reale (servirebbe una vista aggregata e la
 chiusura della lettura riga per riga), o se turni e scout acquistano un gate
 nell'interfaccia: allora le loro policy devono seguirlo.
+
+### DD-024 — Le route che avvisano la squadra chiedono le credenziali
+
+**Data:** 6 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+Le route in `src/routes/api/public/` girano con la service role e saltano la RLS: DD-023 non
+le tocca. Nessuna di loro faceva un controllo di accesso — cercando `authorization` in quella
+cartella l'unico header era lo User-Agent con cui `csi.ts` chiama il portale CSI. Chiunque
+conoscesse l'URL poteva quindi far suonare i telefoni di tutta la squadra:
+`promemoria-palloni` accetta perfino una POST con il corpo vuoto.
+
+La difesa apparente delle altre due — «serve un id evento valido» — non è una difesa: l'id è
+`e` + il timestamp in base 36 (`nuovoIdEvento()`), compare negli URL che la squadra si
+scambia, ed è elencabile da qualsiasi utente loggato.
+
+Il danno non è furto di dati: i testi delle notifiche li costruisce il server. È molestia e
+consumo della quota push. Non è però una ragione per lasciare la porta aperta.
+
+**Decisione**  
+Le tre route che inviano notifiche chiedono le credenziali, con due controlli diversi perché
+i chiamanti sono diversi (`src/lib/auth-route.server.ts`):
+
+- `apri-sondaggio` e `sollecita-presenze` → `richiediAdmin`: token della sessione Supabase
+  verificato con `auth.getUser`, poi ruolo `admin` letto da `user_roles`, la stessa fonte di
+  `src/lib/ruoli.ts` (DD-011). `401` senza token valido, `403` con token ma senza ruolo. Il
+  controllo viene **prima** della validazione dell'input, così la risposta non rivela
+  nemmeno se un evento esiste.
+- `promemoria-palloni` → `richiediSegreto`: intestazione `x-cron-segreto` confrontata con la
+  variabile `CRON_SEGRETO`. La chiama un cron, che una sessione non ce l'ha.
+
+`csi`, `push-config`, `push-subscribe` e `push-messaggio` restano aperte: le chiamano il
+browser prima del login e il service worker, dove qualsiasi segreto sarebbe pubblico.
+
+**Alternative scartate**
+
+- Un segreto condiviso anche per le due route dell'app → finirebbe nel bundle JavaScript,
+  cioè pubblico.
+- Il middleware `requireSupabaseAuth` già presente nel repository → è
+  `createMiddleware({ type: "function" })`, protegge le server function di TanStack Start. In
+  CrAPP `createServerFn` non compare da nessuna parte: quel file non è mai stato eseguito,
+  e non si applica comunque alle route in `src/routes/api/`.
+- Fidarsi dell'id evento come credenziale → è un timestamp in un URL condiviso.
+
+**Conseguenze**
+
+- Se `CRON_SEGRETO` non è configurata, `promemoria-palloni` risponde `503` e il promemoria
+  non parte. È voluto: una porta che si riapre da sola quando manca una variabile
+  d'ambiente non se ne accorge nessuno. Va impostata negli ambienti di deploy e nel cron.
+- I due pulsanti dell'app mandano ora il token con `intestazioniAutenticate()`
+  (`src/lib/auth.ts`), letto al momento della chiamata e non da uno stato React, così non si
+  spedisce un token scaduto.
+- `api.test.ts` non può più verificare la validazione dell'input di `sollecita-presenze`,
+  che ora sta dietro all'accesso: quel pezzo si è spostato in
+  `test/integration/permessi-route.test.ts`, che gira sullo stack locale perché ha bisogno
+  di utenti veri.
+
+**Riesame**  
+Se un giorno l'app userà `createServerFn`, il middleware già presente diventa la strada
+naturale e questi controlli vanno riletti alla sua luce.

docs/modules/notifiche.md

@@ -59,6 +59,21 @@ L'invio effettivo (`src/lib/webpush.server.ts`, funzione `inviaPush`) firma un J
 (ECDSA P-256) e fa una POST senza corpo all'endpoint push del browser; è riusato identico da
 `sollecita-presenze.ts` e `promemoria-palloni.ts`.
 
+### Chi può farle partire (DD-024)
+
+Queste route usano la service role e saltano la RLS, quindi il permesso deve stare nella
+route. `src/lib/auth-route.server.ts` fornisce i due controlli:
+
+| Route                                                    | Controllo                                                                              | Chi la chiama                                                                   |
+| -------------------------------------------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
+| `apri-sondaggio`, `sollecita-presenze`                   | `richiediAdmin` — token della sessione Supabase, poi ruolo `admin` in `user_roles`     | l'app, dal pulsante riservato agli admin                                        |
+| `promemoria-palloni`                                     | `richiediSegreto` — intestazione `x-cron-segreto` uguale alla variabile `CRON_SEGRETO` | un cron, senza sessione                                                         |
+| `csi`, `push-config`, `push-subscribe`, `push-messaggio` | nessuno                                                                                | il browser prima del login e il service worker, che una sessione non ce l'hanno |
+
+**`CRON_SEGRETO` va configurata negli ambienti**: se manca, `promemoria-palloni` risponde
+503 e il promemoria non parte. È voluto — una porta che si riapre da sola quando manca una
+configurazione non se ne accorge nessuno.
+
 ---
 
 ## Notifiche smart
@@ -77,8 +92,11 @@ ripetersi — deduplica puramente locale al dispositivo, non sincronizzata.
   è iscritto o no. Separare i canali richiederebbe schema e UI dedicati.
 - `promemoria_push` è descritta altrove come "storico" ma nel codice è una coda che si
   autocancella alla lettura: non conserva nulla.
-- Nessuna verifica di autenticazione su `push-messaggio` (chiunque conosca un endpoint push
-  valido può leggerne il messaggio) né su `promemoria-palloni`.
+- Nessuna verifica di autenticazione su `push-messaggio`: chiunque conosca un endpoint push
+  valido può leggerne il messaggio. Non è chiudibile con un segreto, perché a chiamarla è il
+  service worker, dove qualsiasi segreto sarebbe pubblico; di fatto la protegge il dover
+  conoscere l'endpoint, che è un URL segreto per dispositivo. `promemoria-palloni` invece è
+  chiusa da DD-024.
 - Compatibilità iOS/Safari non gestita esplicitamente nel codice (nessun branch dedicato):
   serve l'installazione da schermata Home per funzionare, ma l'app non lo segnala
   esplicitamente.

docs/modules/palloni.md

@@ -53,11 +53,12 @@ testo effettivo viene calcolato al volo dal service worker interrogando
 
 ## Limiti noti
 
-- **Nessuna verifica di autenticazione/secret** sulla route `promemoria-palloni`: chiunque
-  può invocarla via POST diretto, nonostante il piano originale prevedesse una protezione
-  con secret.
 - **Nessun cron nel repository**: lo scheduling effettivo (se esiste) è configurato fuori dal
-  codice versionato — da verificare lato Supabase/hosting.
+  codice versionato — da verificare lato Supabase/hosting. Finché non esiste, il promemoria
+  quotidiano non parte da solo.
+- La route è protetta dal segreto previsto dal piano originale (DD-024): chi la chiama deve
+  mandare `x-cron-segreto` uguale alla variabile `CRON_SEGRETO`. Se la variabile non è
+  configurata nell'ambiente la route risponde `503`.
 - Il conteggio dei turni include anche le proposte non confermate: badge e statistiche
   possono contare turni mai effettivamente convalidati da nessuno.
 - La rotazione non considera le assenze dichiarate: può proporre il turno a chi ha risposto
@@ -67,7 +68,6 @@ testo effettivo viene calcolato al volo dal service worker interrogando
 
 ## Evoluzioni possibili
 
-- Aggiungere un secret/header di autorizzazione alla route pubblica.
 - Versionare il cron (es. una migration con `cron.schedule`) invece di configurarlo solo
   lato dashboard.
 - Escludere dalla rotazione chi ha già dichiarato assenza per l'evento.