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 /de/docs/web/admin.md (or send Accept: text/markdown).
Admin-Konsole
Plattform-Inspektion, Ankündigungen und Feature-Flags.
Schritt-für-Schritt für Einsteiger
Voraussetzungen: Lesen Sie die beiden folgenden Einsteigerhandbücher, schließen Sie die lokale Web-Einrichtung ab und öffnen Sie dieses Monorepo im Stammverzeichnis in Ihrem Editor. Webeinstellungen gehören in apps/web/.env.local; Next.js liest das Stammverzeichnis .env nicht. /dashboard im Standard-Fake-Modus ist eine Demo ohne Datenbank; /auth benötigt eine migrierte Datenbank.
Kurze Begriffe: Ein Arbeitsbereich umfasst die einzelnen Benutzer, Daten und Einstellungen eines Teams. Der Server ist das vertrauenswürdige Backend; Halten Sie Anbieterschlüssel aus Browser- und Telefoncodes fern. Eine Migration ist eine versionierte Datenbankänderung, die Tabellen erstellt oder aktualisiert. Ein KI-Modell ist der Motor, der antwortet; Der Modellkatalog ist die Liste der verfügbaren Modell-IDs und Preise des Servers. Ein Anbieter ist ein externer Dienst wie ein KI-, E-Mail- oder Abrechnungsdienst. Eine Berechtigung ist eine Bewilligung, die einem Arbeitsbereich die Nutzung einer Funktion ermöglicht. Ein Webhook ist eine Nachricht, die ein Dienst an den URL eines anderen Dienstes sendet.
1. Bevor Sie ein lokales Testkonto erstellen, fügen Sie Ihre eigene Adresse zur Nur-Server-Liste ADMIN_EMAILS hinzu und starten Sie die App neu.
2. Melden Sie sich bei der migrierten Testdatenbank an und öffnen Sie /admin. Überprüfen Sie die verfügbaren Benutzer- und Organisationsseiten.
3. Dadurch wird Plattformadministrator, nicht Arbeitsbereichseigentum gewährt. Wenn der Zugriff verweigert wird, überprüfen Sie die genaue E-Mail- und Serverkonfiguration. Erhöhen Sie keine willkürlichen Benutzer und testen Sie nicht anhand der Produktion.
Beginnen Sie für benutzerdefinierten Code mit dem bereitgestellten prompts/README.md und kopieren Sie die nächstgelegene Eingabeaufforderung: prompts/new-app-screen.md für einen App-Bildschirm oder prompts/new-landing-page.md für eine öffentliche Seite. Geben Sie Ihrem Programmieragenten für Server-, Datenbank- oder Anbieterarbeiten die Aufgabe dieses Handbuchs und bitten Sie ihn, AGENTS.md, .ai/PROJECT_CONTEXT.md und passende .ai/-Spiegel zu lesen; Überprüfen Sie die hier genannten genauen Quelldateien. Listen Sie Dateien auf und prüfen Sie sie vor der Bearbeitung. Bewahren Sie den Arbeitsbereichseigentum und die Nur-Server-Geheimnisse. und zeige dir den Unterschied. Teilen Sie ihm das gewünschte Verhalten, Eingabe- und Ausgabefelder, zulässige Rollen, erwartete Erfolge und Fehler sowie das Testkonto, den Anbieter oder das Gerät mit. Beispielwerte verwenden; Fügen Sie niemals ein echtes Geheimnis ein.
Admin-Grenze einrichten
ADMIN_EMAILS ist eine nur auf dem Server verfügbare, kommaseparierte Bootstrap-Liste. Aufgeführte Benutzer erhalten bei der Anmeldung die Plattform-Admin-Rolle. Ohne diese Liste vergeben Sie Zugriff über einen autorisierten Datenbank- oder Admin-Pfad; machen Sie nicht den ersten beliebigen Besucher zum Admin.
Plattform-Admins sind von Workspace-Ownern und -Admins getrennt. /admin und die Seiten für Benutzer, Organisationen, Flags, Ankündigungen und Warteliste prüfen die Plattformrolle.
Implementierte Steuerelemente verwenden
Die Better-Auth-Standard-Engine bietet die Admin-Verwaltung von Benutzern, Sperren und Impersonation. Die App setzt Plattformansichten mit Audit-Trails zusammen. Beschränken Sie Impersonation auf verifizierte Admins, machen Sie den Status sichtbar und stellen Sie beim Beenden die ursprüngliche Admin-Sitzung wieder her.
Auth.js übernimmt Admin-Plugins von Better Auth nicht automatisch. Prüfen Sie admin.ts, admin-actions.ts und das Auth-Provider-Verhalten, bevor Sie die Engine wechseln.
Privilegierte Aktionen überprüfen
Testen Sie Ablehnung für Nicht-Admins, Admin-Zugriff, Sitzungen gesperrter Benutzer, Start und Ende der Impersonation sowie alle aktivierten Aktionen. Halten Sie Admin-Routen von der öffentlichen Indexierung fern.
Einrichtung und Konfiguration
Die /admin-Oberfläche ist die Inspektionssicht des Operators über Workspaces, Mitglieder und Produktzustand. ADMIN_EMAILS (oder die Admin-Plugin-Konfiguration im konsumierenden Produkt) entscheidet, wer sie erreicht; jede Admin-Route prüft Autorisierung auf dem Server erneut.
Feature-Flags (feature-flag-runtime.ts) schalten alles Nicht-Konfigurierte standardmäßig aus — ein fehlendes Flag kann nie still eine Oberfläche aktivieren — und pro-Flag-Overrides leben in der featureFlagOverride-Tabelle.
/admin operator dashboard
announcement-actions.ts broadcast in-app notices
resolveFeatureFlags(...) bulk flag resolution for a caller contextImplementierungsablauf
Nutze Admin-Aktionen für Inspektion und Support-Operationen (Workspace-Lookup, Member-Management, Announcement-Broadcast). Halte Mutationen auditiert und Autorisierung an der Aktionsgrenze geprüft, nicht an der Nav.
Rolle Features hinter Flags aus: Code dunkel shippen, pro Workspace oder global aktivieren und das Flag entfernen, sobald die Oberfläche permanent ist. Plattform-Impersonation bleibt eingefroren, es sei denn die PRODUCT.md des Produkts autorisiert sie explizit.
Überprüfung und Fehlerbehebung
Verifiziere, dass ein Nicht-Admin verweigert wird, ein deaktiviertes Flag seine Oberfläche end-to-end verbirgt (Nav, Route, Aktion), ein Override nur für sein Target auflöst und Ankündigungen die vorgesehene Audience erreichen. Admin-Tests sollten zuerst den verweigerten Pfad abdecken.