Files
InsanityLab-web/apps/platforms
Adriano 77829b2d12 longevity: crea l'accesso al sito per un cliente che ha già il fascicolo
accessoDi/collegaAccesso in anagrafica.ts (e le varianti sul singleton
accessoDelCliente/collegaAccessoCliente) leggono e scrivono il legame
clienti.user_id restando l'unico punto che apre identity. accesso.ts
aggiunge creaAccessoCliente: crea l'utente cliente, lo collega, e se il
collegamento fallisce cancella l'utente appena creato (compensazione,
due database, stesso schema di creaCliente). Nuova pagina del
gestionale pages/longevity/gestionale/cliente/[code]/accesso.astro:
genera username e password una volta sola, niente redirect, no-store.

Refs #8
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 13:00:48 +00:00
..

InsanityLab — aree riservate (apps.insanitylab.it)

Applicazione Astro autosufficiente con le tre aree riservate: Biohacking Campus, Stress Index e Longevity. Nasce il 03/09/2026 separando dal sito (apps/sito, insanitylab.it) tutto ciò che sta dietro un login.

Cosa la rende separata

Sito Quest'app
Host insanitylab.it apps.insanitylab.it
Utenti 3 redazionali (admin, superuser, user) uno per ogni cliente del centro (piattaforme, cliente, trainer, admin)
Database insanitylab.db (contenuti, articoli, utenti del sito) piattaforme.db + longevity.db + identity.db
Login /admin/login, solo redazione /login, ed è l'unica porta

Non c'è SSO e non c'è cookie condiviso: una sessione del sito qui non vale, ed è la separazione, non un difetto. Le due lib/auth.ts sono parenti ma non sono la stessa cosa — ~170 righe duplicate una volta sola, libere di divergere come già divergono i ruoli.

Sviluppo

npm ci
npm run dev                      # http://localhost:4321
npm test                         # 26 file, 197 test
npm run create-user -- <nome> <password> <ruolo>   # ruoli: piattaforme, cliente, trainer, admin

I dati stanno in data/ (gitignorata): piattaforme.db, longevity.db, identity.db.

Rilascio

⚠️⚠️ Il DNS viene prima del container. apps.insanitylab.it deve già risolvere verso l'IP della VPS quando si alza lo stack: avviarlo prima significa una catena di sfide TLS fallite, e Let's Encrypt limita proprio quelle. La zona è su Aruba, serve un record A apps → l'IP della macchina.

mkdir -p /opt/docker/insanitylab-platforms/data      # i dati stanno FUORI dal clone git
docker compose up -d --build
node scripts/migra-utenti.mjs                        # prova a vuoto
node scripts/migra-utenti.mjs --applica              # porta gli utenti dal DB del sito

Trappole già pagate

⚠️ Le versioni si fissano esatte. ^7.0.5 sulla nuova app aveva risolto ad astro 7.3.0, che con @astrojs/node 11.1.5 non si parla ("./_internal/logger" is not exported) e il build muore. Astro, l'adapter node e l'integrazione react sono pinnati alle stesse versioni che girano in produzione sul sito.

⚠️ security.allowedDomains in astro.config.mjs non è decorativo. Dietro Traefik il TLS termina al proxy: senza quell'elenco Astro ignora X-Forwarded-Proto/Host e il controllo CSRF respinge ogni POST con 403 — cioè il login smette di funzionare e l'errore sembra «credenziali sbagliate».

⚠️ name: insanitylab-platforms nel compose. Senza, il progetto si chiamerebbe platforms (dal nome della cartella) e un down --remove-orphans dato altrove potrebbe toccare container che non sono suoi.

⚠️ Il default di canAccessPath è chiuso, al contrario del sito da cui viene: là le rotte non elencate (blog, upload) erano di chiunque fosse loggato, qui ogni sezione è di qualcuno. Una rotta nuova senza regola risulta vietata, e lo si scopre provandola.

⚠️ Le API rispondono con uno stato, non con un redirect (401/403 su /api/*): mandare un 302 verso il login a chi ha chiesto del JSON produce un 200 con dentro dell'HTML.

⚠️ Stress Index non ha un backend: src/lib/stress-index/data.ts sono dieci clienti inventati scritti a mano. In linea c'è la sua interfaccia, non i suoi dati.