videoteca/docs/adr/0011-interfaccia-admin-e-credenziali.md

0011 — Interfaccia admin = dashboard PocketBase; credenziali in .env

• Stato: Sostituito da 0012
• Data: 2026-10-11

Contesto

L'admin (un solo superuser, ADR 0009) deve caricare, modificare ed eliminare filmati e categorie (F-11). Decisioni dell'utente del 2026-10-11: iniziare con la dashboard di PocketBase; la password in .env.

Decisione

• Interfaccia admin dell'MVP: la dashboard di PocketBase. Nessuna pagina di gestione nostra; il frontend (ADR 0007) è solo per gli utenti che guardano. Una pagina di gestione propria è rimandata e, se serve, avrà un nuovo ADR (motivo probabile: stato di ricodifica poco visibile dalla dashboard, vedi F-03).
• Credenziali: email e password del superuser stanno in .env nella radice, mai committato (in .gitignore). Il repo contiene solo .env.example con nomi e valori fittizi. Lo script di avvio legge .env e crea il superuser al primo avvio.
• .env serve solo alla creazione iniziale. Dopo, la password vive nel DB di PocketBase: cambiarla da dashboard non aggiorna .env, e viceversa. Per evitare ambiguità, .env non è la fonte di verità della password dopo il primo avvio.

Alternative considerate

• Pagina di gestione propria dal giorno uno: più codice e più superficie da proteggere prima di aver validato la pipeline.
• Password solo nell'installer web: nessun file da proteggere, ma non ripetibile in modo scriptato.

Conseguenze

• ✔ Nessun codice di gestione nell'MVP.
• ✘ Dalla dashboard l'upload è meno guidato e lo stato processing / ready / error si vede solo guardando il record.
• ✘ Password in chiaro su disco: accettabile solo perché il server è locale (127.0.0.1); permessi del file ristretti all'utente, mai nei log né nel changelog.
• Da verificare in M0/M1: l'host del file .env e come lo script lo legge (nessuna libreria: solo shell); se esiste un comando per aggiornare un superuser già esistente (nella documentazione consultata è confermato solo superuser create); dimensione massima di upload dalla dashboard.

Fonti

• https://pocketbase.io/docs/going-to-production/ (consultata 2026-10-11): il primo superuser si crea con il comando superuser create EMAIL PASS o con il link dell'installer web scritto nei log. Nessun meccanismo generale per i segreti: le impostazioni sono salvate in chiaro nel DB; l'unica variabile d'ambiente citata serve a cifrarle (--encryptionEnv).
• https://pocketbase.io/docs/use-as-framework/ (consultata 2026-10-11): non descrive la creazione di superuser da CLI né credenziali via variabili d'ambiente. Quindi PocketBase non legge la password da .env da solo: lo fa lo script di avvio.