Направление работ: Back Код раздела: 1.1.2 Аккаунты и пользователи > Организация аккаунтов > Вход в систему Статус: черновик Ответственный: Панкова Л.А. Версия: 0.2 Обновлено: 04.09.26
1. Назначение
Вход в систему подтверждает, что пользователь владеет учетными данными активного аккаунта.
Система принимает идентификационные данные и пароль, проверяет их корректность и выдает токены доступа для работы с системой.
Процесс входа унифицирован для интерфейсов платформы; интерфейсные сценарии описываются в соответствующих фронтовых разделах.
Вход и доступ к работе — разные вещи. Приглашенный сотрудник входит успешно, но кабинета партнера не получает, пока не завершит Приглашение: токен ему выдается ограниченного назначения.
2. Ключевые понятия
Вход в систему — стандартная авторизация по идентификационным данным аккаунта и паролю.
Аккаунт — цифровое представление пользователя в системе, которое хранит учетные данные, состояние и доступы.
Активный аккаунт — аккаунт, для которого завершены обязательные подтверждения и доступна работа в системе в пределах выданных прав.
Учетные данные — данные для входа в аккаунт: идентификационные данные и пароль.
Идентификационные данные — значение, по которому система находит аккаунт при входе. В рамках стандартного входа используется номер телефона или подтвержденный email.
Пароль — секретное значение, которое пользователь передает вместе с идентификационными данными для подтверждения владения аккаунтом.
Токен доступа — технический ключ, который подтверждает успешный вход и позволяет выполнять запросы от имени аккаунта.
Назначение токена — пометка, сужающая круг методов, доступных предъявителю. Токен без назначения — обычный: им можно все, на что хватает прав. Назначение — не права: права считает модель доступа, а назначение определяет, какие методы вообще доступны такому токену.
Онбординг — состояние, в котором человек вошел по Приглашению и еще не завершил его: действующих записей сотрудника у него нет ни одной, работать ему не с чем. Токен онбординга открывает только путь дозаполнения профиля.
3. Scope
Входит
S1 Учетные данные для входа: разрешенные идентификационные данные и пароль.
S2 Результат входа: проверка учетных данных и состояния аккаунта, выдача токенов и их назначения, ограничения безопасности.
Не входит
- Back 1.1 — Организация аккаунтов
- Back 1.1.1 — Регистрация
- Back 1.1.3 — Восстановление доступа
- Back 1.1.4 — Дополнительные способы регистрации и входа
- UI и фронтовые сценарии входа: Mobile 1.3 — Регистрация и авторизация / WebLk 1.2 — Авторизация / Widget 3.1 — Авторизация пользователя / AdmLk 1.1 — Авторизация / Catalog 3.1 — Авторизация
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Требование | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1: BR1.1.2-1 | Для входа может использоваться одно из разрешенных идентификационных данных Аккаунта | Разрешенные значения: номер телефона и email или логин, если он подтвержден | Бизнес | 1 | Реализовано |
| S1: BR1.1.2-2 | Для входа по идентификационным данным обязательно передается пароль | Если пароль не передан или не совпадает с учетными данными аккаунта, вход не выполняется | Системное | 1 | Реализовано |
| S2: BR1.1.2-3 | Вход разрешен для любого живого Аккаунта; работу в кабинете партнера открывает только состояние S5 | Архивированный Аккаунт токенов не получает и направляется в процесс регистрации — повторная регистрация тем же номером его восстанавливает. Приглашенный в состоянии S4 входит успешно и получает токен назначения «онбординг» — см. BR1.1.2-5. Отказывать ему во входе нельзя: временный пароль из Приглашения и есть способ подтвердить номер телефона. Состояния — Back: 1.1 | Бизнес | 1 | Реализовано OQ1.1.2-2 |
| S2: BR1.1.2-4 | Система при входе должна применять общие ограничения безопасности и не раскрывать, какое именно поле введено неверно | Правила валидации учетных данных и лимиты попыток описаны в Back 1.1. При ошибке идентификационных данных или пароля возвращается единая ошибка входа | Системное | 3 | Не реализовано OQ1.1.2-4 |
| S2: BR1.1.2-5 | Токен, выданный по незавершенному Приглашению, должен нести назначение «онбординг» и открывать только путь дозаполнения профиля | Открыты: получение своего Аккаунта, признаков подтверждения email и телефона, правка своих персональных данных, отправка и проверка кода подтверждения email, смена пароля, продление токена и выход. Все прочие методы такому токену закрыты с сообщением о незаполненном профиле. Признак онбординга спрашивается у записей сотрудника, а не у полноты профиля: правило «нет подтвержденного email — нет доступа» закрыло бы дверь действующим владельцам зон, у которых почта не подтверждена. Административный контур под правило не подпадает: сотрудников партнерских зон туда не пускают вовсе. | Системное | 1 | Реализовано |
| S2: BR1.1.2-6 | Назначение токена должно пересчитываться при каждой выдаче, включая продление | Перенеси назначение из старого токена — и продление стало бы способом выйти из онбординга, ничего не подтвердив. | Системное | 1 | Реализовано |
| S2: BR1.1.2-7 | Ограничение доступа незавершенного Приглашения должно держаться и без шлюза | Второй рубеж — модель доступа: роли достаются только действующей записи сотрудника, поэтому запрос мимо шлюза прав тоже не найдет. Назначение токена — удобный отказ, а не единственная защита. | Системное | 1 | Реализовано |
| S2: BR1.1.2-8 | Ответ входа должен нести признак незавершенного Приглашения отдельным полем | Содержимое токена — дело шлюза и сервиса, а не того, кто его предъявляет: фронт не должен разбирать токен, чтобы понять, вести ли человека на дозаполнение. | Системное | 1 | Реализовано |
| S2: BR1.1.2-9 | Завершение Приглашения должно выдавать полноценный токен, не требуя повторного входа | Приглашение завершается подтверждением email. С этой минуты записи сотрудника действуют, но токен на руках все еще помечен онбордингом, и до нового токена кабинет закрыт. | Системное | 1 | Реализовано |
5. Открытые вопросы
Пин контекста (повторная сверка по итогам дейликов, 2026-09-08): BRD v0.2 · Репозиторий кода:
booking-monorepo, веткаorigin/main, commit82359296(2026-09-07) · Якорь домена:src/services/booking.authentication(Identity/Account/Login — команды и репозиторий входа, онбординга, подтверждения email),src/services/booking.apigateway(RPC-авторизация, whitelist методов онбординга),src/services/booking.abac(маппинг методов на объекты доступа),deploy-charts/microservices/values-api-gateway.yaml(боевой конфиг шлюза) · Гайдбук: не передан — маршрутизация без сверки с гайдбуком.
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| OQ1.1.2-1 | Гайдбук | Подтвердить, используется ли логин как значение для входа в текущей реализации | Продукт | Closed | ||
| OQ1.1.2-2 | Код Б1 | Код: вход по телефону фильтрует IsArchived==false && PhoneNumberConfirmed==true — неактивный/неподтверждённый просто «не найден» (NotFoundException), без явного редиректа в регистрацию; явного состояния «активный» нет (см. BR1.1-3).Решение: достаточно ли трактовать «активность» как (неархивный + подтверждён телефон), и нужен ли сигнал «направить в регистрацию» вместо общей ошибки «не найдено»? AccountRepository.cs:158-162; LoginInternalCommandHandler.cs:90 Логин: вход по email ищет по Email ИЛИ UserName (GetAccountByEmailWithPasswordAsync), при этом BRD упоминает только телефон и подтверждённый email как идентификаторы (а «уникальный логин» вынесен в открытый вопрос OQ1.1.2-1 как отсутствующий в реализации).Расхождение: код допускает вход по UserName — относится ли это к «логину», который, по OQ, из статьи убран? Подтвердить статус входа по UserName. AccountRepository.cs:139-143 (Email или UserName) | Бизнес | Open | 1) Реализовано 2) Логин на будущую реализацию (вес 3). UserName = логин | |
| OQ1.1.2-3 | Код Б2 | Код: вход по email фильтрует только IsArchived==false, НЕ проверяет EmailConfirmed (ищет по Email ИЛИ UserName); асимметрия с телефонным входом, где PhoneNumberConfirmed проверяется.Решение: должен ли неподтверждённый email допускаться ко входу — и если нет, это правка кода (см. также программный П1)? Добавить фильтр EmailConfirmed==true?AccountRepository.cs:139-143 | Бизнес | Open | Вес: 2 Реализовать через статус код (email) | |
| OQ1.1.2-4 | Код П2 | Код: логин выдаёт РАЗНЫЕ ошибки — NotFoundException «Пользователя не существует» (нет аккаунта) vs AuthorizationException «Неверный пароль».Расхождение: прямое нарушение, поле различимо по типу/тексту ошибки. Свести к единому ответу входа? LoginInternalCommandHandler.cs:90 vs :104 | Бизнес | Open | ||
| OQ1.1.2-5 | Код BR1.1.2-9 | Требование говорит: завершение Приглашения выдает полноценный токен без повторного входа. В коде подтверждение email включает записи сотрудника, но токена не выдает вовсе: метод подтверждения ничего не возвращает. Человек остается с онбординговым токеном, и кабинет ему по-прежнему закрыт — до продления токена или повторного входа. |VerifyEmailCodeCommandHandler.cs — включение записей сотрудника без выдачи токена| | Разработка | Open | Завести метод подтверждения email для кабинета партнера, который после успешной проверки кода выдает новую пару токенов уже без назначения «онбординг». Назначение и так пересчитывается при каждой выдаче (BR1.1.2-6), поэтому отдельной логики снятия пометки не нужно. | Делаем: отдельный метод подтверждения кода email для кабинета партнера, возвращающий нормальный токен. |
| OQ1.1.2-6 | Код BR1.1.2-5 | Что нашли: три метода из белого списка онбординга — отправка кода подтверждения email, проверка кода и запрос признаков подтверждения — помечены в коде как неиспользуемые (Obsolete("unused")). Витрину справочника методов уже поправили, а атрибуты в коде остались. Методы при этом несущие: без них дозаполнение профиля не закрывается.|VerifyEmailCodeCommand.cs:7; SendEmailVerificationCodeCommand.cs:7; GetEmailAndPhoneConfirmedQuery.cs:8| | Разработка | Open | Снять Obsolete с трех методов заодно с работой по OQ1.1.2-5. Пометка «неиспользуемый» на методе из белого списка шлюза читается как приглашение его удалить. | |
| OQ1.1.2-7 | Код BR1.1.2-9 | Что нашли: метод VerifyEmailCodePartner (Authentication.Application/Accounts/Commands/LK/VerifyEmailCode/VerifyEmailCodePartnerCommandHandler.cs) закрывает требование BR1.1.2-9 и вопрос OQ1.1.2-5 — после проверки кода подтверждения email выдаёт новую пару токенов без назначения «онбординг». Метод включён в боевой белый список онбординга шлюза (deploy-charts/microservices/values-api-gateway.yaml:122-133, запись IdentityService.VerifyEmailCodePartner) и в маппинг объектов доступа ABAC (AuthenticationAccessObjectBodyMapper.cs:184).Расхождение: дефолтный конфиг сервиса API Gateway ( appsettings.json, из которого шаблонизируется appsettings.Development.json для окружений без Helm values) этот метод в список онбординга не включает — там только IdentityService.VerifyEmailCode (старый метод без выдачи токена). Локальная/тестовая среда, поднятая от дефолтного конфига, отклонит вызов онбординговым токеном с ошибкой «Профиль не заполнен».|deploy-charts/microservices/values-api-gateway.yaml:122-133 (метод включён); src/services/booking.apigateway/Musbooking.ApiGateway/appsettings.json:42-52 (метод отсутствует)| | Разработка | Open | Синхронизировать дефолтный appsettings.json API Gateway со списком OnboardingMethods из values-api-gateway.yaml, добавив IdentityService.VerifyEmailCodePartner, чтобы поведение локальной разработки не расходилось с боевым. |