Как создать сайт с личным кабинетом: роли, данные и проверка доступа

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

Для примера возьмём учебный сервис заявок на обслуживание: клиент отправляет обращение и видит его статус, сотрудник обрабатывает заявки. Ниже — план первой версии и задание для ИИ. Это проектный пример, а не описание уже проверенного клиентского приложения.

Решите, зачем посетителю входить

Личный кабинет оправдан, если человеку нужно возвращаться к своим данным: видеть заявки, продолжать работу или получать закрытые материалы. Для обычной страницы услуги может хватить контакта или формы — регистрация добавит лишний шаг.

Сформулируйте результат одним предложением: «Клиент видит свои обращения и узнаёт, какие уже обработаны». Оно задаёт границы первой версии. Чат, бонусы и оплату можно обсуждать позже, когда основной путь работает.

Отдельно выберите способ доступа: открытая регистрация или приглашение. Не оставляйте этот вопрос на усмотрение генерации: для закрытого сервиса список пользователей может определять сотрудник.

Опишите роли через конкретные действия

Для нашего примера достаточно трёх ролей:

• Гость: видит описание сервиса и экран входа; заявки ему недоступны.
• Клиент: создаёт заявку и читает только собственные обращения; не меняет служебный статус.
• Сотрудник: просматривает заявки и меняет их статус; полномочия выдаёт владелец приложения.

Уточняйте права отдельно для чтения, создания, изменения и удаления. Фраза «клиент работает со своими заявками» не объясняет, можно ли редактировать уже принятое обращение. В первой версии можно запретить редактирование после отправки и вообще не добавлять удаление.

Роль сотрудника не должна появляться после выбора пункта в регистрационной форме. Назначение расширенных прав — отдельное действие уполномоченного владельца.

Задайте данные и состояния экранов

Заявке нужны идентификатор, владелец, тема, описание, время создания и статус. Для начала выберите три статуса: «Новая», «В работе», «Завершена». Не храните лишние сведения о клиенте, если они не нужны сценарию.

Владельца заявки сервер определяет по вошедшему пользователю. Недостаточно передать из формы произвольное поле «клиент» и довериться ему.

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

Передайте ИИ задание на один законченный сценарий

В Lovarus опишите приложение в новом проекте или укажите, какую часть существующего сайта дополняете:

Создай первую версию сервиса заявок с личным кабинетом.
Гость видит описание и вход. Клиент регистрируется,
входит, создаёт заявку и видит только свои обращения.
Сотрудник видит заявки и меняет статус:
Новая → В работе → Завершена.

Поля заявки: тема, описание, владелец, время и статус.
Владельца определяй на сервере по текущему пользователю.
Клиент не назначает себе роль сотрудника,
не меняет владельца или служебный статус.
Удаление и редактирование отправленной заявки пока не нужны.

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

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

Пользователи вашего приложения и аккаунт владельца в Lovarus — разные сущности. Настройки проекта описаны в справке о пользователях приложения. Согласуйте предложенную схему, затем доведите один маршрут от входа до повторного открытия сохранённой заявки.

Проверьте кабинет двумя тестовыми пользователями

Используйте свои тестовые аккаунты и вымышленные обращения. Один аккаунт не покажет, умеет ли система разделять данные разных клиентов.

1. Клиент А создаёт заявку с пометкой TEST-A. После обновления страницы запись остаётся.
2. Клиент Б создаёт TEST-B. В его кабинете нет TEST-A.
3. В аккаунте Б откройте прямую ссылку на тестовую заявку А. Система не должна отдавать её содержание.
4. Попробуйте предусмотренным тестом изменить служебный статус от имени клиента. Сервер должен отказать, даже если кнопку изменения скрыли.
5. Сотрудник меняет статус TEST-A. Клиент А видит изменение после обновления, клиент Б по-прежнему не получает чужую запись.
6. Выйдите и повторно откройте защищённый адрес. Данные не должны возвращаться без действующей авторизации.

Это базовые проверки, а не полный аудит безопасности. Правила нужно применять на сервере при каждом обращении к данным; интерфейсные ограничения их не заменяют. Такой подход описан в рекомендациях OWASP по контролю доступа.

Что считать готовой первой версией

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

Остальные части сайта пройдите по чек-листу перед публикацией. Сохраните список ролей и тестовых сценариев: после добавления файлов, оплаты или новых типов пользователей его нужно расширить и повторить проверку.