Adminconsole

Walkthrough voor beginners

Vereisten: Lees de twee onderstaande beginnershandleidingen, voltooi de lokale webconfiguratie en open deze monorepo in de root van uw editor. Webinstellingen horen thuis in apps/web/.env.local; Next.js leest de root .env niet. /dashboard in de standaard nepmodus is een demo zonder database; /auth heeft een gemigreerde database nodig.

Korte termen: een werkruimte bestaat uit de afzonderlijke gebruikers, gegevens en instellingen van één team. De server is de vertrouwde backend; houd providersleutels uit de browser- en telefooncode. Een migratie is een versiebeheer van de database, waarbij tabellen worden gemaakt of bijgewerkt. Een AI-model is de motor die antwoord geeft; de modelcatalogus is de serverlijst met beschikbare model-ID's en prijzen. Een provider is een externe service, zoals een AI-, e-mail- of factureringsservice. Een recht is een subsidie ​​waarmee een werkruimte een functie kan gebruiken. Een webhook is een bericht dat de ene service naar de URL van een andere service verzendt.

1. Voordat u een lokaal testaccount aanmaakt, voegt u uw eigen adres toe aan de server-only ADMIN_EMAILS-lijst en start u de app opnieuw.

2. Meld u aan bij de gemigreerde testdatabase en open /admin; bekijk de beschikbare gebruikers- en organisatiepagina's.

3. Dit geeft platformbeheerder en geen eigendom van de werkruimte. Als toegang wordt geweigerd, controleer dan de exacte e-mail- en serverconfiguratie; verhoog geen willekeurige gebruikers en test niet tegen de productie.

Voor aangepaste code begint u met de meegeleverde prompts/README.md en kopieert u de dichtstbijzijnde prompt: prompts/new-app-screen.md voor een app-scherm of prompts/new-landing-page.md voor een openbare pagina. Voor server-, database- of providerwerk geeft u uw codeeragent de taak van deze handleiding en vraagt ​​u hem om AGENTS.md, .ai/PROJECT_CONTEXT.md en overeenkomende .ai/-mirrors te lezen; inspecteer de exacte bronbestanden die hier worden genoemd; maak een lijst van bestanden en controleer deze voordat u deze bewerkt; behoud van het eigendom van de werkruimte en geheimen voor de server; en laat je het verschil zien. Vertel het gewenste gedrag, invoer- en uitvoervelden, toegestane rollen, verwacht succes en fouten, en het testaccount, de provider of het apparaat. Gebruik voorbeeldwaarden; plak nooit een echt geheim.

• Voordat u begint
• Basisbeginselen van de terminal
• Lokale webinstellingen
• Agentprompts en projectgeheugen

Maak de beheerdersgrens

ADMIN_EMAILS is een door komma's gescheiden bootstrap-lijst die alleen op de server staat. Vermelde gebruikers krijgen bij aanmelding de rol van platformbeheerder. Zonder dit kunt u toegang verlenen via een geautoriseerd database-/beheerderspad; maak van de eerste willekeurige bezoeker geen beheerder.

Platformbeheerder verschilt van de eigenaar/beheerder van de werkruimte. /admin en zijn gebruikers-, organisatie-, vlag-, aankondigings- en wachtlijstpagina's controleren de platformrol.

Gebruik de geïmplementeerde controles

De standaard Better Auth-engine biedt beheerdersgebruikersbeheer, verbanningen en nabootsing van identiteit. De app stelt platformweergaven samen met audittrails. Beperk imitatie tot geverifieerde beheerderstoegang, maak de status ervan zichtbaar en herstel de oorspronkelijke beheerderssessie bij het afsluiten.

Auth.js neemt de Better Auth-beheerdersplug-ins niet automatisch over. Controleer het gedrag van admin.ts, admin-actions.ts en de auth-provider voordat u van engine wisselt.

Controleer bevoorrechte acties

Test weigering door niet-beheerder, beheerderstoegang, sessies met verboden gebruikers, start/stop van nabootsing van identiteit en de acties die u inschakelt. Houd alle beheerroutes buiten openbare indexering.

• Functievlaggen
• Aankondigingen
• Wachtlijstbeheer

Setup en configuratie

Het /admin-oppervlak is de operator-inspectieview over workspaces, leden en productstatus. ADMIN_EMAILS (of de admin-pluginconfiguratie in het consumerende product) bepaalt wie er komt; elke admin-route controleert autorisatie opnieuw op de server.

Feature flags (feature-flag-runtime.ts) schakelen standaard alles uit dat niet geconfigureerd is — een ontbrekende flag kan nooit stilletjes een oppervlak inschakelen — en per-flag overrides leven in de featureFlagOverride-tabel.

/admin                    operator dashboard
announcement-actions.ts   broadcast in-app notices
resolveFeatureFlags(...)  bulk flag resolution for a caller context

Implementatieworkflow

Gebruik admin-acties voor inspectie en support-operaties (workspace-lookup, ledenbeheer, aankondigings-broadcasts). Houd mutaties geaudit en autorisatie gecontroleerd aan de actiegrens, niet in de nav.

Rol features uit achter flags: ship code dark, schakel in per workspace of globaal, en verwijder de flag zodra het oppervlak permanent is. Platform-impersonation blijft bevroren tenzij het PRODUCT.md van het product het expliciet autoriseert.

Verificatie en probleemoplossing

Verifieer dat een non-admin wordt geweigerd, dat een uitgeschakelde flag zijn oppervlak end-to-end verbergt (nav, route, actie), dat een override alleen voor zijn target resolvet en dat aankondigingen het beoogde publiek bereiken. Admin-tests moeten eerst het denied-pad dekken.