Да. Как только описание приложения предполагает необходимость входа в систему, в нём реализуется полноценное управление учётными записями — а не один общий пароль. Администратор может создавать дополнительные учётные записи: с правами пользователя (создание, изменение и удаление данных) или только для чтения — каждая со своим собственным логином. Создание выполняется на экране «Настройки», где выдаётся одноразовый временный пароль, который пользователь обязан заменить при первом входе.
Что на практике означает «несколько пользователей»
Сгенерированное приложение, требующее входа в систему, поддерживает три чётко разделённые роли: администратор, редактор и только для чтения. Администратор, помимо использования приложения, управляет учётными записями; пользователь создаёт, изменяет и удаляет данные так же, как администратор, но не может управлять доступом других пользователей; роль «только для чтения» позволяет просматривать данные, но не вносить в них изменения. Каждый пользователь заходит под своим логином — это не общий пароль, разделяемый всей командой. Благодаря этому любое действие можно точно проследить до конкретного человека.
Эта функция не требует отдельного включения: как только в описании проекта фигурирует необходимость авторизации (например, доступ ограничен вашей командой, в отличие от публичной страницы), управление учётными записями автоматически включается в генерируемый код.
Как создаётся учётная запись
Администратор переходит на экран «Настройки», вводит логин нового пользователя и выбирает роль — редактор или только для чтения — затем подтверждает создание. Приложение выдаёт одноразовый временный пароль, который отображается единожды и больше никогда не будет доступен ни администратору, ни кому-либо ещё. Пользователь использует его для первого входа и обязан сразу же задать свой собственный пароль.
Учётную запись можно деактивировать — процесс происходит в два шага (сначала клик для подготовки, затем второй клик для подтверждения), а не через стандартное окно браузера, которое может заблокировать интерфейс при использовании некоторых инструментов автоматизации. Администратор не может деактивировать ни свою собственную учётную запись, ни последнюю активную учётную запись администратора — иначе восстановить контроль над доступом станет невозможно.
Что действительно запрещает роль «только для чтения»
Ограничение действует не только на уровне интерфейса. Если учётная запись с такой ролью попытается создать, изменить или удалить данные — даже напрямую через API, минуя интерфейс — сервер отклонит запрос до того, как будет выполнена любая операция записи. Это не просто скрытая кнопка: защита применяется на уровне каждого вызова, независимо от способа его инициации.
Чего в системе нет
Две ограничения указаны чётко и без обиняков. Во-первых, роли глобальны для всего приложения: нет гранулярных прав на уровне отдельных сущностей или разделов (например, «этот пользователь видит клиентов, но не видит раздел биллинга») — доступ либо полный (редактирование), либо строго ограниченный (только чтение). Во-вторых, в сгенерированных приложениях отсутствует двухфакторная аутентификация: основная защита — одноразовый временный пароль и обязательная смена пароля при первом входе. Дополнительный фактор не предусмотрен. Если вашему бизнесу нужны более тонкие права или двухфакторная аутентификация, вы можете передать готовый код (стандартный Next.js и Prisma, полностью экспортабельный) разработчику — он легко добавит эти функции поверх существующей базы.