Можно ли сделать вход пользователей и личный кабинет

Да. Подключите коннектор Supabase, опишите в промпте, кто логинится и что видит после входа, и Zugo соберёт регистрацию, вход и личный кабинет. Аккаунты живут в Supabase Auth под вашим аккаунтом. Одна вещь остаётся на вас всегда: проверить, что каждый пользователь видит только свои строки.

Вопрос почти никогда не про кнопку «Войти». Он про то, что происходит после неё: у кого какой доступ, где хранится пароль и кому принадлежат аккаунты, если вы завтра смените инструмент. Разберём по порядку.

Что вообще входит в «вход пользователей»?

Четыре разные вещи, которые в разговоре сливаются в одну. Регистрация: человек заводит аккаунт. Аутентификация: система убеждается, что это он. Сессия: он остаётся залогиненным между визитами. Авторизация: система решает, что именно ему показать.

Первые три генерация закрывает уверенно, потому что это стандартный набор, одинаковый почти в любом продукте. Четвёртая зависит от вашей предметной области, и именно на ней ломаются сборки: система прекрасно отличает залогиненного от анонимного и при этом показывает залогиненному чужие заказы.

Отсюда практический вывод. В промпте про вход важнее описать не форму, а правило видимости. «Пользователи регистрируются по email» это половина задачи. «Пользователи регистрируются по email и видят только свои заказы, а администратор видит все» это задача целиком.

Где хранятся аккаунты и пароли?

В Supabase Auth, то есть в проекте Supabase, который заведён на ваш аккаунт. Zugo не держит отдельную базу пользователей вашего приложения: сгенерированный код обращается к вашему проекту, а таблица пользователей и хеши паролей остаются там же, где вы можете их увидеть в дашборде.

Это важно по двум причинам, и обе практические. Первая: вы в любой момент видите список зарегистрированных людей, можете сбросить доступ или удалить аккаунт, не спрашивая никого. Вторая: если вы перестанете пользоваться Zugo, база пользователей никуда не денется, потому что она изначально не была внутри Zugo.

Нижняя строка таблицы это то, о чём обычно вспоминают поздно. Подтверждение почты, сброс пароля и уведомления это письма, а письмам нужен отправитель. Коннектор Resend закрывает эту часть, но текст писем стоит перечитать: сгенерированная формулировка это черновик.

Как описать роли в промпте?

Перечислить их списком и для каждой назвать, что она видит и что может менять. Это самая недооценённая часть запроса. Генерация не угадает, что у вас «мастер» и «администратор» это разные уровни доступа, если вы об этом не сказали.

Слабо: «сайт с личным кабинетом». Сильно: «Сервис записи к репетитору. Ученик регистрируется по email, видит только свои занятия и может отменить занятие за сутки. Репетитор видит расписание всех своих учеников. Администратор видит всё и может завести репетитора».

В этой формулировке есть три роли, правило видимости для каждой и одно бизнес-ограничение. Последнее почти наверняка потребует отдельной правки: специфичное условие вроде «за сутки» доводится уточнениями, а не появляется идеально с первого раза.

Ещё одна привычка: сразу скажите, нужна ли открытая регистрация. Приложения для своих и приложения для публики устроены по-разному, и «регистрация только по приглашению администратора» это отдельное требование, которое нужно назвать словами.

Что чаще всего идёт не так?

Четыре сценария, и все они повторяются от проекта к проекту, поэтому проще проверить их сразу, чем обнаружить через месяц.

Фильтр вместо ограничения. Список показывает только ваши записи, но приходят с сервера все. На экране всё выглядит правильно, а данные утекают. Ловится не глазами, а вторым аккаунтом.

Единственная роль. Вы описали двух пользователей, а получили одного: любой залогинившийся может всё. Обычно это значит, что в промпте не было глагола «может» применительно к каждой роли по отдельности.

Регистрация без выхода. Форма входа есть, кнопки выхода нет, и вы это замечаете только тогда, когда нужно проверить второй аккаунт. Просите выход явным пунктом.

Молчаливая ошибка. Неверный пароль ничего не показывает, письмо для сброса не приходит. Тексты ошибок и письма это часть входа, а не украшение, и о них надо сказать в описании.

Каждое из четырёх лечится одной правкой за 3 кредита. Дороже обходится не исправление, а то, что проблему нашли поздно, когда в приложении уже сидели живые пользователи.

Что проверить сразу после сборки?

Три вещи, в этом порядке, потому что каждая ломается по-своему.

Сначала базовый цикл: зарегистрируйтесь, выйдите, войдите заново, сбросьте пароль. Это самая частая и самая заметная поломка, и она видна за две минуты.

Потом изоляцию данных. Заведите двух пользователей и убедитесь, что второй не видит записи первого. Проверять надо именно так, живыми аккаунтами, а не глядя на интерфейс: список может фильтроваться на экране и при этом отдаваться целиком.

Потом права в самой базе. Откройте дашборд Supabase и посмотрите политики доступа к таблицам. Любое приложение с пользовательскими данными, собранное генерацией или руками, заслуживает такой ревизии до того, как в нём появятся настоящие люди. Как подключается сам коннектор, описано в статье AI-приложение с Supabase.

Проверка перед выдачей здесь помогает мало, и это стоит понимать честно. Каждая сборка запускается в песочнице, и та, что не открылась, помечается как неудачная вместо того, чтобы уехать к вам как результат. Риск белого экрана это снижает, но не убирает, и про правильность прав доступа не говорит ничего.

Сколько стоит приложение с входом?

Ровно столько же, сколько приложение того же размера без входа: авторизация не тарифицируется отдельно. Сборка стоит 6 кредитов, правка 3, многостраничная платформа 12 за первые три страницы и по 3 кредита за каждую следующую. Hi-Fi удваивает: сборка 12, правка 6.

Тарифы: Free даёт 5 кредитов единоразово, Pro стоит $25 в месяц и даёт 200 кредитов, Business стоит $99 в месяц. Оговорка про Free честная: 5 кредитов чуть меньше одной сборки, поэтому первый прогон начинается на платном плане.

Реалистичная смета выглядит так. Одна сборка на основу, дальше три-пять правок на роли и видимость, ещё две-три на письма и тексты ошибок. То есть проект с нормально работающим входом обычно укладывается в двадцать-тридцать кредитов, а 200 кредитов Pro дают 66 правок, если тратить их только на доводку. Аккаунт Supabase оплачивается отдельно и имеет свой бесплатный уровень.

Где границы у сгенерированной авторизации?

Четыре, и все они про ответственность, а не про технику.

• Права доступа надо пересматривать самому. Генерация делает разумное предположение о том, кто что видит. Предположение и требование это разные вещи, а цена ошибки здесь чужие персональные данные.
• Сложные схемы доступа доводятся правками. Роли с пересечениями, доступ по организациям, временные приглашения: всё это появляется через серию уточнений поверх работающей основы.
• Zugo не заменяет команду на сложном продукте. Если в системе десяток ролей и внешние интеграции, первая версия соберётся быстро, а дальше её ведёт команда.
• Совместная работа над проектом устроена иначе, чем вы ждёте. Аккаунт держит один человек, остальные смотрят опубликованную ссылку. Подробности в статье можно ли работать вдвоём над проектом.

Ни один из пунктов не отменяет пользы. Они означают, что рабочий вход появляется за минуты, а доверять ему настоящие данные стоит после того, как вы сами проверили, кто что видит.

С чего начать?

С одного экрана и двух ролей. Опишите приложение так, чтобы в тексте были глаголы «видит» и «может», подключите Supabase и заведите двух тестовых пользователей сразу после первой сборки.

Если приложение будет ещё и хранить содержательные данные, полезен разбор приложения с базой данных. А сама проверка занимает один вечер: опишите свой сценарий на zugo.dev, зарегистрируйтесь в собственном приложении и посмотрите на список пользователей в дашборде Supabase.