For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/web/admin.md (or send Accept: text/markdown).
Console di amministrazione
Ispezione della piattaforma, annunci e feature flag.
Procedura dettagliata per principianti
Prerequisiti: leggi le due guide per principianti di seguito, completa la configurazione locale del Web e apri questo monorepo alla radice nel tuo editor. Le impostazioni Web appartengono a apps/web/.env.local; Next.js non legge la radice .env. /dashboard nella modalità falsa predefinita è una demo senza database; /auth necessita di un database migrato.
Termini rapidi: uno spazio di lavoro è costituito da utenti, dati e impostazioni separati di un team. Il server è il backend affidabile; mantenere le chiavi del provider fuori dal browser e dal codice del telefono. Una migrazione è una modifica del database con versione che crea o aggiorna tabelle. Un modello AI è il motore che risponde; il catalogo dei modelli è l'elenco del server degli ID e dei prezzi dei modelli disponibili. Un fornitore è un servizio esterno come un servizio di intelligenza artificiale, posta elettronica o fatturazione. Un diritto è una concessione che consente a un'area di lavoro di utilizzare una funzionalità. Un webhook è un messaggio che un servizio invia allo URL di un altro servizio.
1. Prima di creare un account di prova locale, aggiungi il tuo indirizzo all'elenco ADMIN_EMAILS solo server e riavvia l'app.
2. Iscriviti al database dei test migrati e apri /admin; ispezionare le pagine utente e organizzazione disponibili.
3. Ciò garantisce l'amministratore della piattaforma, non la proprietà dell'area di lavoro. Se l'accesso viene negato verificare l'esatta configurazione della posta elettronica e del server; non elevare utenti arbitrari né eseguire test rispetto alla produzione.
Per il codice personalizzato, inizia con prompts/README.md in dotazione e copia il prompt più vicino: prompts/new-app-screen.md per la schermata di un'app o prompts/new-landing-page.md per una pagina pubblica. Per il lavoro su server, database o provider, assegna al tuo agente di codifica il compito di questa guida e chiedigli di leggere AGENTS.md, .ai/PROJECT_CONTEXT.md e i mirror .ai/ corrispondenti; controllare gli esatti file sorgente nominati qui; elencare file e controlli prima della modifica; preservare la proprietà dello spazio di lavoro e i segreti solo del server; e mostrarti la differenza. Indicagli il comportamento desiderato, i campi di input e output, i ruoli consentiti, i successi e gli errori previsti e l'account, il fornitore o il dispositivo di prova. Utilizzare valori campione; non incollare mai un vero segreto.
Crea il confine amministrativo
ADMIN_EMAILS è un elenco di bootstrap separato da virgole solo per server. Gli utenti elencati ricevono il ruolo di amministratore della piattaforma al momento dell'iscrizione. Senza di esso, concedere l'accesso tramite un percorso database/amministratore autorizzato; non rendere amministratore il primo visitatore arbitrario.
L'amministratore della piattaforma è distinto dal proprietario/amministratore dell'area di lavoro. /admin e le relative pagine utente, organizzazione, bandiera, annuncio e lista d'attesa controllano il ruolo della piattaforma.
Utilizzare i controlli implementati
Il motore Better Auth predefinito fornisce la gestione degli utenti amministratori, i divieti e la rappresentazione. L'app compone visualizzazioni della piattaforma con audit trail. Limita la rappresentazione all'accesso amministrativo verificato, rendi visibile il suo stato e ripristina la sessione amministrativa originale all'uscita.
Auth.js non eredita automaticamente i plugin di amministrazione Better Auth. Esaminare admin.ts, admin-actions.ts e il comportamento del provider di autenticazione prima di cambiare motore.
Verificare le azioni privilegiate
Testa il rifiuto da parte di utenti non amministrativi, l'accesso amministrativo, le sessioni degli utenti esclusi, l'avvio/arresto della rappresentazione e le azioni che abiliti. Mantieni tutti i percorsi amministrativi fuori dall'indicizzazione pubblica.
Installazione e configurazione
La superficie /admin è la vista di ispezione dell'operatore su workspace, membri e stato del prodotto. ADMIN_EMAILS (o la configurazione del plugin admin nel prodotto consumatore) decide chi ci arriva; ogni route admin ricontrolla l'autorizzazione sul server.
I feature flag (feature-flag-runtime.ts) disabilitano di default tutto ciò che non è configurato — un flag mancante non può mai abilitare silenziosamente una superficie — e gli override per flag vivono nella tabella featureFlagOverride.
/admin operator dashboard
announcement-actions.ts broadcast in-app notices
resolveFeatureFlags(...) bulk flag resolution for a caller contextFlusso di implementazione
Usa le azioni admin per ispezione e operazioni di supporto (ricerca workspace, gestione membri, broadcast di annunci). Mantieni le mutazioni auditate e l'autorizzazione controllata al confine dell'azione, non nella nav.
Rilascia le funzionalità dietro flag: shippa il codice in dark, abilitalo per workspace o globalmente, e rimuovi il flag quando la superficie è permanente. L'impersonation di piattaforma resta congelata a meno che il PRODUCT.md del prodotto la autorizzi esplicitamente.
Verifica e risoluzione dei problemi
Verifica che un non-admin sia negato, che un flag disabilitato nasconda la sua superficie end-to-end (nav, route, azione), che un override si risolva solo per il suo target e che gli annunci raggiungano il pubblico previsto. I test admin dovrebbero coprire prima il percorso negato.