davideandClaude Opus 5
847972b582
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>
CrAPP 🏐
CrAPP è una Progressive Web App sviluppata per digitalizzare completamente la gestione di una squadra di pallavolo.
Funzionalità principali
- Gestione squadra
- Gestione presenze
- Calendario allenamenti e partite
- Scout Live
- Badge e gamification
- Statistiche
- Notifiche intelligenti
- Gestione amministrativa
- AI per la pianificazione degli allenamenti (in sviluppo)
Stack tecnologico
React 19, TypeScript, TanStack Start (SSR), Vite 8, Tailwind CSS 4, motion, vaul, Supabase (PostgreSQL, Auth, Storage), Vercel, GitHub. Dettagli in docs/ARCHITECTURE.md.
Avvio locale
Le dipendenze si installano con bun (bun.lock):
bun install
npm run dev # http://localhost:8080
Comandi
npm run build # build di produzione
npm run lint # eslint (include prettier)
npm run test # test unit; npm run test:all per la suite completa
Chi aggiunge o modifica una funzione scrive anche il test e lo lascia verde (test/README.md).
Deploy
Deploy automatico su Vercel a ogni push su main, che è anche il branch di lavoro corrente.
develop pubblica un Preview Deployment, ma oggi è indietro rispetto a main. Su quale branch
committare lo decide chi sviluppa (DD-019).
Variabili d'ambiente
Il progetto richiede le seguenti variabili:
SUPABASE_URLSUPABASE_PUBLISHABLE_KEYVITE_SUPABASE_URLVITE_SUPABASE_PUBLISHABLE_KEY
Documentazione
Indice in docs/README.md. Le regole per gli assistenti AI stanno in AGENTS.md, lo stato corrente del lavoro in PROJECT_STATE.md.