Направление работ: Back Код раздела: 1.1.3 Аккаунты и пользователи > Организация аккаунтов > Восстановление доступа Статус: черновик (почти готов) Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 05.06.26
1. Назначение
Восстановление доступа позволяет пользователю задать новый пароль, если он не может войти в Аккаунт по текущим учетным данным.
Система принимает номер телефона или подтвержденный адрес электронной почты, определяет Аккаунт, отправляет данные для сброса пароля, проверяет код сброса и сохраняет новый пароль.
2. Ключевые понятия
Восстановление доступа — процесс подтверждения владения Аккаунтом через данные для сброса пароля и последующей смены пароля.
Идентификационные данные — номер телефона или подтвержденный адрес электронной почты, по которым пользователь инициирует восстановление доступа.
Данные для сброса пароля — код и сопутствующая информация, которые система отправляет на доступный канал связи пользователя.
Код сброса пароля — шестизначный цифровой код на телефон и на почту, который пользователь вводит для подтверждения права задать новый пароль.
Маскирование контакта — скрытие части номера телефона или адреса электронной почты в ответе системы.
3. Scope
Входит
S1 Инициация восстановления и поиск аккаунта
S2 Отправка данных для сброса: выбор канала отправки и вызов нужного шаблона уведомления и работа с повторными запросами.
S3 Код сброса: создание, хранение, проверка и ограничение срока жизни четырехзначного кода.
- Сброс пароля и установка нового: прием кода сброса и нового пароля, сохранение нового пароля после успешной проверки.
Не входит
- Вход в систему — Back: 1.1.2
- Регистрация — Back: 1.1.1
- Общая модель Аккаунта, учетных данных и прав доступа — Back: 1.1
- Дополнительные способы регистрации и входа — Back: 1.1.4
- Шаблоны уведомлений и правила доставки сообщений — Back: 7.1
- UI и фронтовые сценарии интерфейсов — Mobile: 1.4 / WebLk: 1.3 / Widget: 3.3 / Catalog: 3.3
- Администрирование текстов ошибок и системных параметров — Back: 8.4
4. Требования
Правила и ограничения бизнеса на уровне данных, источник истины в системе
| ID | Правило | Комментарий | Тип требования | Вес | Статус |
|---|---|---|---|---|---|
| S1 BR1.1.3-1 | Восстановление доступа может быть инициировано по номеру телефона или адресу электронной почты. | В запросе также передается источник, чтобы система определила интерфейс, из которого начато восстановление. | Системное | 1 | Реализовано |
| S1 BR1.1.3-2 | Восстановление доступа также может инициироваться через отправку сообщения в службу поддержки. | Система отправляет сообщение на почту с набором данных: номер телефона или email. | Бизнес | 2 | Не реализовано OQ1.1.3-3 |
| S1 BR1.1.3-3 | Система должна найти Аккаунт по переданным идентификационным данным. | Если Аккаунт не найден, система возвращает статус ошибки. | Системное | 1 | Реализовано |
| S1 BR1.1.3-4 | Для архивированного Аккаунта восстановление доступа не выполняется. | Такой аккаунт может заново совершить регистрацию, чтобы войти в систему. | Бизнес | 1 | Реализовано |
| S2 | Если у Аккаунта указан подтвержденный адрес электронной почты для сброса пароля, первая отправка данных для сброса выполняется на почту. | Если почта не указана, данные сразу отправляются на номер телефона по СМС или через мессенджер (в будущем). | Бизнес | 1 | Про подтвержденную почту открытый вопрос в Back: 1.1.2 |
| S2 BR1.1.3-5 | Повторный запрос данных для сброса становится доступен после таймаута. | Системное | 2 | Реализовано | |
| S2 BR1.1.3-6 | Вторая отправка выполняется на тот же канал, что и первая. | Если у Аккаунта нет почты, повторная отправка выполняется на номер телефона. | Бизнес | 2 | Реализовано |
| S2 BR1.1.3-7 | Третья отправка выполняется на номер телефона по СМС или через мессенджер (в будущем) по истечению таймаута. | Бизнес | 3 | Реализовано OQ1.1.3-4 | |
| S2 BR1.1.3-8 | После третьей отправки инициация восстановления доступа задерживается на 60 минут. | Системное | 3 | Реализовано | |
| S3 BR1.1.3-9 | Код сброса пароля действует только в пределах установленного таймаута в соответствии с попыткой: 0/1мин/1мин/1час. | Просроченный код не должен приниматься для смены пароля. После успешной смены пароля использованный код сброса становится недействительным. | Системное | 2 | Реализовано OQ1.1.3-5 OQ1.1.3-11 |
| S3 BR1.1.3-10 | Смена пароля выполняется только после успешной проверки кода сброса. | Метод сброса принимает код сброса и новый пароль, после чего возвращает статус результата и сопровождающий текст. | Системное | 1 | Реализовано |
| S3 BR1.1.3-11 | Ответ на запрос восстановления содержит статус результата, таймаут повторного запроса, замаскированный контакт и сопровождающий текст. | Техническое | 2 | Частично реализовано OQ1.1.3-10 | |
| S3 BR1.1.3-12 | Номер телефона и email в ответе системы должны маскироваться. | Телефон: countryCode(первые 3 цифры)*****последние2Email-маска ( ab*******@домен) | Системное | 3 | Реализовано |
| S3 BR1.1.3-13 | Ошибки выполнения возвращаются по общим текстам и кодам ошибок системы. | Подробные тексты и системные параметры описаны в Back: 7.1 | Техническое | 2 | Реализовано |
| S3 BR1.1.3-14 | При сбросе пароля запрещено повторное использование ранее использованного пароля | Системное | 2 | Реализовано |
5. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус | Рекомендации |
|---|---|---|---|---|---|
| OQ1.1.3-1 | Лайза и Никита | Что делает система после получения службой поддержки сообщения о просьбе восстановления доступа? BR1.1.3-2 | Герман | Closed | |
| OQ1.1.3-2 | Код Б1 | Код: состояния «заблокированный» в модели нет вовсе (есть только IsArchived, PhoneNumberConfirmed); правило «не выполнять восстановление для заблокированного» проверить не на чем.Решение: что такое «заблокированный аккаунт» в предметной области и нужно ли вводить это состояние? Account.cs:13-103 (нет state/blocked); not_found (состояние blocked) | Бизнес / Разработка | Closed | |
| OQ1.1.3-3 | Код Б2 | Код: хендлер RestorePassworSuportdLKCommandHandler существует, но тело пустое — // TODO: реализовать, return Unit без действий.Расхождение: функционал не реализован (заглушка). Подтвердить приоритет/целевое поведение поддержки восстановления (см. OQ1.1.3-1, Closed). RestorePassworSuportdLKCommandHandler.cs:34-38 | Бизнес / Разработка | Open | |
| OQ1.1.3-4 | Код Б4 | Код: с 3-й попытки канал принудительно SMS (`shouldUseSms = AttemptNumber>=3 | Email пуст`) — поддержано; но «таймаут перед третьей отправкой» и блокировка после неё не соответствуют BRD (см. программные П5/П6). Решение: подтвердить целевую лестницу каналов/таймаутов. SendRestorePasswordCodeInternalQueryHandler.cs:111-113 | Бизнес / Разработка | |
| OQ1.1.3-5 | Код П1 | Код: срок жизни кода единый TemporaryPasswordLifetime (по умолчанию 1 час), не зависит от номера попытки.Расхождение: фактический TTL не совпадает ни по значениям, ни по зависимости от попытки. Какой целевой TTL кода? AuthenticationSettings.cs:8; SendRestorePasswordCodeInternalQueryHandler.cs:86-87; ValidateRestorePasswordCodeInternalQueryHandler.cs:74 | Бизнес / Разработка | Closed | |
| OQ1.1.3-6 | Код П2 | BRD: код сброса — ЧЕТЫРЁХзначный на телефон и ШЕСТИзначный на почту (повторено в Scope). Код: код всегда 6 цифр ( GenerateTemporaryPassword: цикл for i<6, char[6]); XML-doc метода ошибочно говорит «длиной в 4 символа»; в тестовом режиме код фиксированный 123456.Расхождение: 4-значного кода на телефон нет. Привести BRD к 6 цифрам или код — к разной длине по каналу? ApplicationHelpers.cs:19-35 | Разработка | Closed | Поменять в доках |
| OQ1.1.3-7 | Код П3 | Код: rate-limit PasswordResetMobile даёт задержки 0/1мин/1мин/1час (т.е. задержка 1 час после 4-й попытки, далее сброс счётчика) — это не «3 отправки → блок 60 мин».Расхождение: и порог (3 vs 4), и семантика (задержка vs блокировка). RateLimitPolicy.cs:38-48; SendRestorePasswordCodeInternalQueryHandler.cs:67-74 | Бизнес / Разработка | Closed | |
| OQ1.1.3-8 | Код П4 | Код: MaskPhone даёт countryCode(первые 3 цифры)*****последние2 — структура близка, но без разделителей ()/-**- из примера BRD. Email-маска совпадает (ab*******@домен).Расхождение: формат телефонной маски не совпадает с примером. Зафиксировать целевой формат. ApplicationHelpers.cs:64-73 | Бизнес / Разработка | Closed | |
| OQ1.1.3-9 | Код П5 | Код: rate-limit задаёт задержки между запросами (0/1м/1м/1ч), второй канал = первый при AttemptNumber<3 (выбор только по наличию Email) — частично поддержано, но значения таймаутов не совпадают с BR1.1.3-9 (60с/6мин).Частично: механизм «тот же канал» есть, тайминги расходятся. RateLimitPolicy.cs:38-48; SendRestorePasswordCodeInternalQueryHandler.cs:111-113 | Бизнес / Разработка | Closed | |
| OQ1.1.3-10 | Код П6 | Код: статус (PasswordResetCodeSendState) и маскирование контакта есть; «таймаут повторного запроса» и «сопровождающий текст» в составе ответа не подтверждены за обход.Частично/не найдено за обход: подтвердить состав DTO ответа. PasswordResetCodeSendState.cs; ApplicationHelpers.cs:64-73 — поля timeout/текст не найдены за обход | Разработка | Open | Частично реализовано Вес: 2 |
| OQ1.1.3-11 | Код П7 | Код: после смены удаляется validated-JWT (PasswordResetTokenValidatedKey), при отправке нового кода удаляется старый; прямого удаления САМОГО кода в SetNewPassword нет.Частично: код инвалидируется косвенно (через удаление validated-токена и при следующей отправке), но не явным удалением кода по факту смены. Достаточно ли этого? SetNewPasswordQueryHandler.cs:99; SendRestorePasswordCodeInternalQueryHandler.cs:91 | Разработка | Closed | |
| OQ1.1.3-12 | Код П8 | Код: при сбросе пароля запрещено повторное использование ранее использованного пароля (IsPasswordInHistoryAsync → состояние PasswordAlreadyUsed); хранится PasswordHistory.В BRD 1.1.3 это правило не описано. Нужно ли требование «запрет повторного пароля при сбросе» и какова глубина истории? SetNewPasswordQueryHandler.cs:79-88; PasswordHistory.cs; SetNewPasswordState.cs | Бизнес | Closed | Добовить в брд |