Направление работ: Back Код раздела: 1.1.2 Аккаунты и пользователи > Организация аккаунтов > Вход в систему Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 19.06.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Частично реализовано OQ1.1.2-3
S1: BR1.1.2-2Для входа по идентификационным данным обязательно передается парольЕсли пароль не передан или не совпадает с учетными данными аккаунта, вход не выполняетсяСистемное1Реализовано
S2: BR1.1.2-3Вход разрешен только для активного АккаунтаНеактивный Аккаунт не получает токены доступа и должен быть направлен в процесс регистрацииБизнес1Частично реализовано (логин не активен) OQ1.1.2-2
S2: BR1.1.2-4Система при входе должна применять общие ограничения безопасности и не раскрывать, какое именно поле введено неверноПравила валидации учетных данных и лимиты попыток описаны в Back 1.1. При ошибке идентификационных данных или пароля возвращается единая ошибка входаСистемное3Не реализовано OQ1.1.2-4

5. Открытые вопросы

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)
БизнесOpen1) Реализовано
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

0 items under this folder.