Авторизация и личный кабинет в сайте и приложении
Как спланировать общий аккаунт, историю заказов, роли и восстановление доступа на сайте и в приложении. Что проверить перед запуском.
Общий личный кабинет сайта и приложения начинается не с одинаковой формы входа, а с одной учётной записи клиента и согласованных прав. Покупатель должен узнавать свои заказы на любом устройстве. При этом сотрудник, партнёр и обычный клиент могут видеть разные данные, даже если входят через похожие экраны.
До разработки полезно разделить два вопроса: как система узнаёт человека и что разрешает ему делать. Первый — проверка личности при входе. Второй — авторизация, то есть проверка прав. Для владельца бизнеса это означает, что успешного ввода пароля недостаточно, чтобы открыть пользователю любой заказ или документ.
1. Решите, что действительно должно быть общим
Начните со списка данных, которые клиент ожидает найти после входа: история заказов, адреса, избранное, бонусы, документы. Не включайте всё автоматически. Например, общая корзина нужна не каждому проекту, а её объединение после гостевого просмотра требует отдельных правил.
Для каждого раздела запишите источник данных и ожидаемое поведение. Если заказ создан на сайте, должен ли он сразу появиться в приложении? Если адрес исправлен на телефоне, меняются ли уже оформленные заказы? Обычно исторические данные заказа и текущие настройки профиля нужно различать, но конкретное правило определяет ваш процесс.
Затем проверьте существующие аккаунты. Один человек мог зарегистрироваться по почте, а позже оформить заказ по телефону без входа. Совпадение имени не даёт основания объединять записи. Связывание аккаунтов должно подтверждать право пользователя на оба способа доступа, иначе можно открыть чужую историю.
Если кабинет уже есть на сайте на 1С-Битрикс, сначала стоит проверить его роли, дополнительные модули и доступные способы интеграции. Переносить экран без разбора этих правил недостаточно: приложение должно работать с тем же клиентом, а не создавать похожую запись в другой базе.
2. Выберите способы входа и восстановления
Почта с паролем, одноразовый код и внешний провайдер входа решают задачу по-разному. Выбор зависит от аудитории, существующей базы и доступности канала подтверждения. Не нужно добавлять все варианты только потому, что они встречаются в других приложениях.
Обсудите не только успешный вход, но и обычные затруднения:
- Письмо или код не пришли: как повторить отправку и куда обратиться.
- Человек сменил телефон: как восстановить доступ без выдачи чужого аккаунта.
- Вход выполнен на чужом устройстве: как завершить сеанс.
- Пользователь поменял пароль: что происходит с ранее открытыми сеансами.
- Внешний сервис входа недоступен: какой путь остаётся у существующего клиента.
Общая учётная запись не означает, что вход на сайте автоматически откроет приложение. У каждого устройства может быть отдельный сеанс. Это нормально, если пользователь понимает, что входит в тот же профиль, и не обязан регистрироваться заново.
Для смены важных контактных данных предусмотрите подтверждение. Поддержке тоже нужны правила: какие сведения она вправе запросить и какие действия не выполняет по одному сообщению в чате. Иначе аккуратная форма входа соседствует с небезопасным восстановлением вручную.
3. Опишите права через реальные действия
Вместо общей фразы «будут роли» составьте список действий. Покупатель смотрит собственные заказы; сотрудник обрабатывает назначенные обращения; администратор управляет доступами. Для корпоративного кабинета добавьте границы организации: сотрудник одной компании не должен видеть документы другой.
Скрытая кнопка не заменяет проверку доступа. OWASP рекомендует проверять разрешения при каждом запросе к защищённым ресурсам. Значит, сервер должен отклонить запрещённое действие, даже если запрос пришёл не из обычного интерфейса.
В приёмку включите попытку открыть чужой заказ и действие после отзыва роли. Проверяйте отдельно просмотр, изменение и выгрузку: право читать документ не обязательно даёт право его редактировать. Для критичных операций полезно сохранять журнал действий, чтобы можно было разобраться, кто и когда внёс изменение.
4. Проверьте весь путь клиента
Пройдите сценарий с двумя тестовыми пользователями, а не только с администратором. Первый регистрируется на сайте, оформляет заказ и входит в приложение. Второй не должен увидеть его данные. Затем поменяйте контакт, восстановите доступ и завершите сеанс на одном устройстве.
Отдельно согласуйте удаление аккаунта: что происходит с доступом, связанными данными и незавершёнными заказами. Для приложений с созданием аккаунта правила Apple предусматривают возможность инициировать удаление внутри приложения. Google Play для подпадающих под требование приложений требует также доступный веб-путь запроса удаления. Это не то же самое, что временная блокировка профиля; применимость и детали проверяют перед выпуском.
Перед разработкой приложения пришлите список ролей, разделов кабинета и способов входа. Я разберу, что можно использовать из существующей системы, какие правила нужно уточнить и что включить в оценку. Готовое техническое задание для первого обсуждения не требуется.