Направление работ: Back Код раздела: 1.1 Аккаунты и пользователи > Организация аккаунтов Статус: на валидации Ответственный: Панкова Л.А. Версия: 0.2 Обновлено: 05.06.26


1. Назначение

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

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

2. Ключевые понятия

Аккаунт — централизованная сущность пользователя. Хранит учетные данные, состояние и выданные доступы.

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

Активный аккаунт — аккаунт, для которого выполнены обязательные условия регистрации: подтвержден телефон, задан пароль, принято согласие на обработку данных и выданы стартовые permissions.

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

Заблокированный аккаунт — аккаунт, заблокированный в системе.

Токен доступа — технический ключ, который подтверждает, что аккаунт прошел аутентификацию, и позволяет системе выполнять запросы от имени этого аккаунта. В системе используются два типа токенов: краткосрочный access token для доступа к API и долгосрочный refresh token для получения нового access token без повторного входа.

Учетные данные — данные для входа в Аккаунт. Обязательные: номер телефона, пароль, Email для партнерской зоны. Необязательные: уникальный логин, Email для клиентской зоны.

3. Scope

Входит

S1: Аккаунт

  • Схема данных.
  • Связь Аккаунта и Карточки клиента.
  • Состояния Аккаунта и ограничения действий по состояниям.

S2: Валидация и ограничения

  • Общие правила хранения и проверки учетных данных.
  • Общие лимиты попыток подтверждения и ввода учетных данных.
  • Общая защита от ботов и DDoS-атак.

Не входит

  • Регистрация как процесс — Back: 1.1.1
  • Вход в систему — Back: 1.1.2
  • Восстановление доступа — Back: 1.1.3
  • Дополнительные способы регистрации и входа — Back: 1.1.4
  • Бизнес-логика Карточки клиента и партнерских данных клиента — Back: 1.3
  • Партнерская зона и ее настройки — Back: 1.4.1

4. Требования

Правила и ограничения бизнеса на уровне данных, источник истины в системе

IDТребованияКомментарийТип требованияВесСтатус
S1: BR1.1-1Аккаунт хранит только учетные данные, состояние и выданные доступы.Персональные данные, история заказов, отношения с партнерами и CRM-данные хранятся в Карточке клиента.Техническое1Реализовано
S1: BR1.1-2Аккаунт не может существовать без связанной Карточки клиента.Одна карточка клиента не может быть связана с несколькими активными аккаунтами, и один активный аккаунт не может быть связан с несколькими карточками.

Карточка клиента и ее связь с аккаунтом описана в https://wiki.yandex.ru/homepage/d750da42741c/texnicheskaja-dokumentacija/brd/dokumentacija-po-funkcionalurazdelam/1-akkaunty-i-polzovateli/1.3-klienty/
Системное1OQ1.1-2
Реализовано
S1: BR1.1-3Аккаунт может находиться только в допустимых состояниях: неактивный, активный, заблокированный.Неактивный аккаунт ограничен в действиях до выполнения обязательных условий активации.

Заблокированные не могут войти в систему, восстановить доступ могут через службу поддержки.
Бизнес1Реализовано частично
S1: BR1.1-4Для аккаунта доступны архивирование и восстановлениеВосстановление происходит в результате регистрации https://wiki.yandex.ru/homepage/d750da42741c/texnicheskaja-dokumentacija/brd/dokumentacija-po-funkcionalurazdelam/1-akkaunty-i-polzovateli/1.1-organizacija-akkauntov-v-sisteme/1.1.1-registracija/Бизнес2Реализовано частично
S1: BR1.1-5Для создания Аккаунта из учетных данных является обязательным только номер телефона и пароль.Бизнес1Реализовано
S2: BR1.1-6Аккаунт после удаления хранится в течение 5 лет.После истечения 5 лет все данные из связанной карточки клиента удаляются.Бизнес2Не реализовано
S2: BR1.1-7В рамках организации Акаунтов учетные данные являются уникальными кроме пароля.Системное1OQ1.1-3
Частично реализовано
S2: BR1.1-8Email и телефон должны подтверждаться 6-ти значным кодом.Системное1Реализовано
S2: BR1.1-9Код должен иметь ограниченный срок действия, ограниченное число попыток ввода и ограничение на повторную отправку.Системное1OQ1.1-5
Частично реализовано
S2: BR1.1-10Система предусматривает и ограничивает количество попыток подтверждения учетных данных.Таймаут применяется к подтверждению телефона, email.Системное2OQ1.1-6
Частично реализовано
S2: BR1.1-11Система ограничивает количество попыток ввода учетных данных.При превышении лимита дальнейшие действия временно блокируются.Системное2Не реализовано
S2: BR1.1-12Для поддержки используются 2 токена: долгосрочный для аутентификации и краткосрочный для автообновление долгосрочного.Для мобильного приложения 2 недели

Для партнерской и админский зон 24 часа
Техническое3OQ1.1-7
Частично реализовано
S2: BR1.1-13Система поддерживает несколько активных сессий и позволяет избегать повторной авторизации в течение длительного периода.Бизнес3Не реализовано

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

IDИсточникВопросКомуСтатусРекомендации
OQ1.1-1Код
Б3
Код: уникальность телефона/email при проверке включает АРХИВНЫЕ аккаунты (фильтр IsArchived закомментирован) — архивный аккаунт блокирует повторную регистрацию того же телефона/email. В BRD 1.1 (S2, уникальность учетных данных) поведение для архивных не оговорено.

Решение: должен ли архивный аккаунт «держать» телефон/email или они должны освобождаться?
БизнесOpenВнесено в БРД тут и в 1.1.1 и 1.1.3
OQ1.1-2Код
П1
Код: связь реализована как соглашение по совпадению Id (Account.Id = clientId ?? Guid.NewGuid()), карточка создаётся асинхронно через AccountCreatedEvent; 1:1 НЕ enforce-ится FK/unique-индексом в этой БД. Расхождение: гарантия 1:1 декларативная, не структурная.

Где должна enforce-иться целостность 1:1?

|RegistrationMobileEndCommandHandler.cs:85,106-167; relationships Account↔Client (cross-service, confidence medium)|
РазработкаClosed
OQ1.1-3Код
П2
Код: уникальность телефона/email обеспечивается ТОЛЬКО проверкой в коде, без unique-индекса в БД (RequireUniqueEmail не задан; в миграциях unique только на normalized_username(случайный Guid), normalized_name(роли), invite_code). При гонке возможны дубли телефона/email на уровне БД.

Расхождение: «уникальность» не гарантирована БД. Достаточно ли проверки в приложении или нужен constraint?

|SendRegistrationCodeMobileCommandHandler.cs:51-55; AccountRepository (нет unique-индекса phone/email); ProgramExtenstions.cs:203-212|
РазработкаOpenТехдолг: сделать либо через событие или проверку кэша

Вес: 3
OQ1.1-4Код
П3
Код: подтверждение телефона при регистрации есть (SendVerifyCode/VerifyCode-хендлеры), но при ВХОДЕ по email EmailConfirmed не проверяется (см. 1.1.2), а проверка наличия почты при сбросе игнорирует EmailConfirmed.

Частично: код подтверждения существует, но «подтверждённость email» не enforce-ится на всех путях. Должен ли email везде использоваться только подтверждённым?

|SendRegistrationCodeMobileCommandHandler.cs:57-80; AccountRepository.cs:139-143|
РазработкаOpenПеренести во вход

Вес: 2
OQ1.1-5Код
П4
Код: ограничение на повторную ОТПРАВКУ есть в Widget/LK (rate-limit), но в МОБИЛЬНОЙ регистрации SendRegistrationCodeMobileCommandHandler НЕ вызывает rate-limiter вообще (есть только TTL кэша); ограничения на число попыток ВВОДА кода нет.

Частично: срок жизни и часть лимитов есть, число попыток ввода и повторная отправка в Mobile — не покрыты.

RateLimitPolicy.cs:54-77; SendRegistrationCodeMobileCommandHandler.cs (нет вызова rateLimiter)|
РазработкаOpenДоделать эндпоинт для моб

IdentityService/SendRegistrationCodeMobile
OQ1.1-6Код
П5
Код: rate-limit на отправку кодов есть в части потоков, но «ограничение числа попыток подтверждения» (ввода кода) как отдельный механизм не найдено за обход; в Mobile-регистрации лимита на отправку кода нет. Частично/не найдено за обход.

RateLimitPolicy.cs:54-77; SendRegistrationCodeMobileCommandHandler.cs
РазработкаOpenДоделать эндпоинт для моб

IdentityService/SendRegistrationCodeMobile
OQ1.1-7Код
П6
Код: refresh-токен — случайные 32 байта, отдельного срока жизни refresh нет; ExpiresAt сессии = срок access-токена. Расхождение: (1) «долгосрочности» refresh отдельным lifetime не подтверждено; (2) формулировка BRD инвертирована (краткосрочный обновляет долгосрочный) относительно обычной модели.

Какой целевой lifetime у refresh?

AccountSession.cs:14; not_found (refresh lifetime)
РазработкаOpenРефреш: месяц для моб / сутки для партнерши и админки

Вес: 3
OQ1.1-8КодBRD: Scope S2 заявляет «общую защиту от ботов и DDoS-атак».

Код: captcha/recaptcha/bot/ddos в якоре не найдено за обход; rate-limit только per-account/per-phone. Может жить в apigateway/инфраструктуре — за пределами якоря не проверялось.

Где реализована защита от ботов/DDoS?

grep captcha/bot/ddos — не найдено за обход; DistributedRateLimiter.cs
РазработкаClosedВажна для сайта и виджета, лежит в другом слое: Back 10.4 Безопасность системы

Индепатенция?