BRD Widget 3.3 Восстановление пароля
Направление работ: Widget Код раздела: 3.3 Раздел: Авторизация > Восстановление пароля Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 11.08.26
1. Назначение
Раздел описывает клиентский flow восстановления пароля в виджете.
Клиент переходит к восстановлению из входа, указывает email или телефон, подтверждает восстановление кодом из почты или SMS и задает новый пароль.
Раздел зависит от Back: 1.1.3 Восстановление.
2. Ключевые понятия
Восстановление пароля — клиентский сценарий виджета, в котором клиент подтверждает владение аккаунтом и задает новый пароль.
Восстановление доступа — backend-процесс поиска аккаунта, отправки кода, проверки кода и сохранения нового пароля.
Идентификационные данные — email или телефон, которые клиент указывает для запуска восстановления пароля.
Код восстановления — код из письма или SMS, который клиент вводит для подтверждения восстановления.
Маскирование контакта — скрытие части email или телефона в сообщении о канале отправки кода.
3. Scope
Входит
S1: Запуск восстановления и ввод email или телефона
S2: Подтверждение восстановления через код из почты
S3: Подтверждение через SMS-код и установка нового пароля
S4: Состояния ошибок восстановления
Не входит
- Widget: 3.1 Авторизация > Вход
- Widget: 3.2 Авторизация > Регистрация
- Back: 1.1.3 backend-логика восстановления доступа
- Back: 7.1 шаблоны уведомлений и правила доставки сообщений
4. BR
Указаны в пункте 4 раздела Back: 1.1.3 Восстановление.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
Вердикт по разделу: Не реализовано, раздел описывает целевое состояние. Уточнено 12.08.26: расхождение не в платформе, а в экране виджета. Платформа поддерживает восстановление по коду — метод проверки кода есть в API-слое самого виджета (
verifyRecoveryCode), код отправляется на подтверждённый телефон или почту, по нему клиент подтверждает владение и задаёт новый пароль. Экран виджета этого не использует:PasswordRecovery.vueреализует прежний сценарий — одно полеНе реализованосохраняются до его завершения.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: #FR3.3-1 | Клиент запускает восстановление пароля | Интерфейс открывает экран восстановления, показывает поле Email или телефон и действие Продолжить; продолжение недоступно до ввода данных. | 1 | Не реализовано — экран принимает только email, поля Email или телефон нет | |
| S2: #FR3.3-2 | Клиент указывает телефон для восстановления | Интерфейс после ввода телефона отправляет код на почту, показывает замаскированный email и таймер Новый код через 0:59. После истечения первого таймера интерфейс позволяет отправить второй код на почту; только после истечения таймера второго кода становится доступно действие Отправить код по смс. На SMS-шаге отображается указанный клиентом телефон без маскирования. | 1 | Не реализовано — экран принимает только email, поля Email или телефон нет | |
| S2: #FR3.3-3 | Клиент указывает email для восстановления | Интерфейс после ввода email отправляет код на указанную почту, показывает email в сообщении о письме и таймер Новый код через 0:59. После истечения первого таймера интерфейс позволяет отправить второй код на почту; только после истечения таймера второго кода становится доступно действие Отправить код по смс. SMS используется только как третья попытка для экономии бюджета компании; на SMS-шаге отображается замаскированный телефон. | 1 | Не реализовано | |
| S3: #FR3.3-4 | Клиент подтверждает восстановление и задает новый пароль | Интерфейс принимает код из почты или SMS, после успешного подтверждения открывает поля Пароль и Повторите пароль, позволяет показать или скрыть введенные значения и сохранить новый пароль действием Сохранить; после успешного сохранения клиент переходит к входу. | 1 | Не реализовано — экран не запрашивает код и не даёт задать пароль: показывает «Мы отправили вам новый пароль на электронную почту». Метод проверки кода verifyRecoveryCode в API-слое уже есть и не используется | |
| S4: #FR3.3-5 | Клиент сталкивается с ошибкой поиска аккаунта или ввода SMS-кода | Интерфейс показывает ошибку в текущем контексте восстановления: Клиент с данным телефоном не найден, Клиент с данной почтой не найден или ошибку ввода SMS-кода. При неверном SMS-коде интерфейс показывает состояние ошибки в поле кода и таймер Новый код через 0:59; после истечения таймера позволяет выполнить действие Отправить новый код. Если код введен неверно больше 3 раз, интерфейс показывает сообщение Слишком много попыток. Новый код через 59:59 и возвращает клиента к экрану ввода SMS-кода после истечения часа. | 2 | Не реализовано — ошибки «Клиент с данным телефоном/почтой не найден» на экране не показываются | |
| S4: #FR3.3-6 | Клиент неверно вводит новый пароль | Интерфейс показывает ошибку под полями Пароль и Повторите пароль и не позволяет продолжить, если пароль недопустим: больше 64 символов, меньше 8 символов, содержит недопустимые символы, например +=, или не содержит хотя бы 1 заглавную букву, 1 цифру и спецсимвол. | 2 | Не реализовано |
6. Открытые вопросы
| ID | Источник | Вопрос | Кому | Статус |
|---|---|---|---|---|
| #OQ3.3-1 | Код / QA | Требование говорит: восстановление по email или телефону, код на почту с таймером 0:59, второй код на почту, SMS только третьей попыткой, затем клиент сам задаёт новый пароль. В коде другая механика: только email, новый пароль генерируется системой и отправляется на почту, эскалации на SMS нет. Решение: BRD — целевое состояние, требуется эпик «Восстановление пароля v2» — восстановление по телефону, задание собственного пароля вместо присланного, эскалация email → email → SMS, лимит попыток и блокировка на час. Оценить объём и включить в план. | Разработка | Закрыт |
| #OQ3.3-2 | Код / безопасность | Что нашли: при восстановлении нет проверки существования аккаунта — интерфейс не показывает Клиент с данным телефоном не найден / Клиент с данной почтой не найден (FR3.3-5), а новый пароль отправляется на почту без подтверждения владения. Уточнено 12.08.26 — исходная формулировка была неверной. Пароль на почту без подтверждения владения отправляет экран виджета, а не платформа: сценарий с кодом на подтверждённый телефон или почту существует и поддержан методом verifyRecoveryCode в API-слое виджета, но PasswordRecovery.vue его не вызывает. Соответственно это не пробел в безопасности платформы, а устаревший экран. Работа сводится к переводу экрана на существующий сценарий: запрос кода → подтверждение владения → задание собственного пароля, вместе с показом ошибок «Клиент с данным телефоном/почтой не найден» (FR3.3-5). Отдельного приоритета не требует, входит в эпик 3.3 общим порядком. \ features/auth/ui/PasswordRecovery.vue:10-60, shared/api/auth/api/auth.api.ts:220,317 | Разработка | Закрыт |
| #OQ3.3-3 | BRD | Что проверить: раздел ссылается на Back: 1.1.3 Восстановление как на первоисточник сценария. Перед стартом эпика сверить целевой сценарий виджета с бэкенд-BRD: расхождение может быть уже на уровне бэкенда, тогда доработка нужна и там (эскалация каналов, лимит попыток, сохранение пользовательского пароля). Решение: сверку выполняем позже, непосредственно перед стартом работ по эпику — сейчас не блокирует. К моменту сверки уже известно, что метод проверки кода существует, поэтому проверять нужно частности: эскалацию каналов email → email → SMS, лимит попыток и блокировку на час. | Бизнес | Закрыт |