Ja. Sobald eine beschriebene Anwendung eine Anmeldung erfordert, wird eine echte Benutzerverwaltung integriert – kein einzelnes, gemeinsam genutztes Passwort: Der Administrator kann weitere Konten anlegen – entweder mit der Rolle 'Benutzer' (zum Erstellen, Ändern und Löschen von Daten, ohne Kontoverwaltung) oder mit der Rolle 'Nur-Lesen' (zum Anzeigen ohne Schreibzugriff) – jeweils mit eigenem Benutzernamen. Die Erstellung erfolgt über den Bildschirm „Einstellungen“, wobei ein einmaliges temporäres Passwort vergeben wird, das die betreffende Person bei der ersten Anmeldung durch ihr eigenes ersetzen muss.
Was „mehrere Benutzer“ konkret bedeutet
Eine generierte Anwendung mit Anmeldefunktion kennt drei klare Rollen: Administrator, Benutzer und Nur-Lesen. Der Administrator verwaltet neben der Nutzung der Anwendung auch die Benutzerkonten; der Bearbeiter darf wie der Administrator Daten erstellen, bearbeiten und löschen, darf aber keine Konten verwalten; die Rolle Nur-Lesen dient ausschließlich zum Anzeigen – Schreibzugriff ist nicht möglich. Jede Person meldet sich mit eigenem Benutzernamen an – es gibt kein einziges Passwort, das von einem ganzen Team geteilt wird. Dadurch bleibt jede Aktion bis zur ausführenden Person nachvollziehbar.
Dies ist keine separat aktivierbare Funktion: Sobald Ihre Projektbeschreibung eine Anmeldung vorsieht (zum Beispiel Zugriff nur für Ihr Team im Gegensatz zu einer öffentlichen Seite), gehört die Benutzerverwaltung automatisch zum generierten Ergebnis.
Wie ein Konto angelegt wird
Über den Bildschirm „Einstellungen“ gibt ein Administrator einen Benutzernamen ein, wählt die Rolle (Bearbeiter oder Nur-Lesen) und bestätigt. Die Anwendung antwortet mit einem einmaligen temporären Passwort, das nur ein einziges Mal angezeigt wird – danach ist es weder vom Administrator noch von sonst jemandem einsehbar. Die betreffende Person nutzt es für die erste Anmeldung und muss es dort sofort durch ihr eigenes Passwort ersetzen.
Ein Konto kann deaktiviert werden – die Deaktivierung erfolgt in zwei Schritten (ein Klick zum Vorbereiten, ein zweiter zum Bestätigen), niemals über ein natives Browserdialogfeld, das unter bestimmten Automatisierungstools die Oberfläche einfrieren würde. Ein Administrator kann weder sein eigenes Konto noch das letzte aktive Administratorkonto deaktivieren: Andernfalls wäre die Verwaltung der Zugriffe dauerhaft blockiert.
Was die Rolle „Nur-Lesen“ tatsächlich verhindert
Die Einschränkung wirkt nicht nur optisch. Versucht ein Nur-Lesen-Konto, Daten zu erstellen, zu ändern oder zu löschen – selbst über Umgehung der Oberfläche, etwa per direktem API-Aufruf, wird die Anfrage auf Serverebene abgelehnt, noch bevor auch nur ein einziger Schreibvorgang stattfindet. Es handelt sich also nicht um einen einfach ausgeblendeten Button, sondern um eine Sicherheitsmaßnahme, die bei jedem Aufruf geprüft wird – unabhängig davon, wie dieser ausgelöst wurde.
Was nicht enthalten ist
Zwei Grenzen, klar benannt: Erstens sind die Rollen stets global für die gesamte Anwendung gültig – es gibt keine feingranularen Berechtigungen pro Entität oder Abschnitt („Dieses Konto sieht Kunden, aber nicht die Abrechnung“). Es gibt lediglich die Wahl zwischen Bearbeitung und Nur-Lesen – für alle Bereiche gleichermaßen. Zweitens bietet eine generierte Anwendung keine Zwei-Faktor-Authentifizierung: Das einmalige temporäre Passwort sowie die zwingende Neuauswahl beim ersten Login bilden die vorgesehene Sicherheit – kein zusätzlicher Faktor. Falls Ihr Geschäft feinere Berechtigungen oder 2FA benötigt: Da der Code standardkonformes, exportierbares Next.js und Prisma ist, kann ein Entwickler diese Funktionen problemlos auf Basis des Vorhandenen ergänzen.