Files

T

simone 8158038145 feat(auth): gate OTP email sul portale cliente (v2.3 Phases 23-25)

Il portale /client/<slug> era protetto dal solo token in URL: chiunque
ricevesse o intercettasse il link entrava, per sempre, senza identificarsi.
Ora l'admin registra le email autorizzate per cliente e il cliente si
identifica con un codice usa-e-getta prima di vedere qualsiasi dato.

- Resend 6.18.1 + src/lib/mailer.ts (Result tipizzato, mai catch silenzioso)
- migration 0015 (gia applicata a prod): client_emails, otp_codes,
  clients.sessions_valid_from. Additiva pura, conteggi verificati pre/post
- admin: sezione "Accessi al portale" in /admin/clients/[id] con whitelist
  e revoca sessioni in blocco
- gate: codice 6 cifre CSPRNG, hash SHA-256 (mai il codice in chiaro),
  TTL 15 min, max 5 tentativi, rate limit su entrambi gli endpoint,
  risposta identica per email in whitelist e non (no enumeration)
- sessione: cookie HMAC per-cliente, 90 giorni, httpOnly/secure/lax

Il gate sta in cima alla page, NON nel layout: nell'App Router il segmento
page viene renderizzato in parallelo al layout, quindi gattare nel layout
nascondeva la dashboard a schermo ma lasciava fasi, task e pagamenti nel
payload RSC dell'HTML (46907 byte -> 17594 dopo il fix). Verificato.

Verifica: build OK, 9/9 test E2E in locale contro il DB di produzione.

NON DEPLOYARE prima di: RESEND_API_KEY+RESEND_FROM su Coolify e whitelist
popolata per i 3 clienti reali (oggi vuota) - altrimenti il gate li chiude
fuori dal loro portale. Checklist in .planning/STATE.md.

SEND-01/02 (invio preventivo via email) rinviati a v2.4 su richiesta.

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

2026-07-29 12:10:33 +02:00

1.9 KiB

Raw Blame History

Regola: la memoria di progetto si aggiorna, sempre

.planning/STATE.md è la fonte di verità su dove siamo. È rimasto fermo dal 2026-06-21 al 2026-07-28 mentre venivano chiusi un audit di sicurezza, una riorganizzazione della cartella e mezzo design system: chi riapriva il progetto leggeva uno stato falso. Questa regola esiste per impedire che si ripeta.

Quando aggiornare

Dopo ogni unità di lavoro conclusa — una fase, una migration applicata, un fix deployato, una decisione presa che cambia la rotta. Non a fine milestone: a fine cosa.

Cosa scrivere in `.planning/STATE.md`

Frontmatter: last_updated (ISO, data reale), last_activity, status, progress.
Current Position: fase, stato, e soprattutto se qualcosa blocca.
Blocchi: marcati [BLOCCANTE], con cosa manca e chi/cosa lo sblocca. Un blocco non scritto è un blocco che si riscopre a caro prezzo.
Lezioni: quando un approccio si rivela sbagliato, scrivere perché falliva, non solo cosa si è fatto al suo posto. Serve a non riprovarci fra due mesi.
Date assolute, mai "ieri" o "la settimana scorsa".

Cosa scrivere nella memoria persistente

~/.claude/projects/-Users-simonecavalli-Vault-IAMCAVALLI/memory/ — un file per fatto, più la riga di indice in MEMORY.md.

Ci va quello che non si deduce dal repo: decisioni e il loro perché, vincoli operativi, cose che sono state provate e non funzionano. Non ci va quello che il codice già dice: struttura, cronologia dei fix, contenuto di CLAUDE.md.

Se un fatto in memoria diventa falso, correggerlo o cancellarlo. Una memoria sbagliata è peggio di una memoria assente.

Cosa NON fare

Non scrivere "completato" per lavoro che compila ma non è stato verificato. Distinguere sempre scritto / testato / in produzione — sono tre stati diversi e confonderli è il modo più veloce per deployare un disastro.
Non lasciare STATE.md a raccontare la milestone precedente.

1.9 KiB Raw Blame History