BRD WebLK 1.3 Восстановление пароля
Направление работ: WebLK Код раздела: 1.3 Раздел: Авторизация > Восстановление пароля Статус: черновик Ответственный: Панкова Л.А. Версия: 0.1 Обновлено: 01.07.26
1. Назначение
Раздел описывает пользовательский flow восстановления пароля в WebLK.
Пользователь переходит к восстановлению из входа, указывает email или телефон, подтверждает восстановление кодом из почты или SMS и задает новый пароль.
Если пользователь не помнит данные или не имеет к ним доступа, интерфейс позволяет отправить обращение в поддержку.
Раздел зависит от Back: 1.1.3 Восстановление.
2. Ключевые понятия
Восстановление пароля — пользовательский сценарий WebLK, в котором пользователь подтверждает владение аккаунтом и задает новый пароль.
Восстановление доступа — backend-процесс поиска аккаунта, отправки кода, проверки кода и сохранения нового пароля.
Идентификационные данные — email или телефон, которые пользователь указывает для запуска восстановления пароля.
Код восстановления — код из письма или SMS, который пользователь вводит для подтверждения восстановления.
Маскирование контакта — скрытие части email или телефона в сообщении о канале отправки кода.
3. Scope
Входит
S1: Запуск восстановления и ввод email или телефона
S2: Подтверждение восстановления через код из почты
S3: Подтверждение через SMS-код и установка нового пароля
S4: Обращение в поддержку и состояния ошибок
Не входит
- WebLK: 1.2 Авторизация > Вход
- WebLK: 1.1 Авторизация > Регистрация партнера
- Back: 1.1.3 backend-логика восстановления доступа
- Back: 7.1 шаблоны уведомлений и правила доставки сообщений
4. BR
Указаны в пункте 4 раздела Back: 1.1.3 Восстановление.
5. Функциональные требования (UC + FR)
FR — functional requirements, что интерфейс должен уметь делать по определенному UC.
| ID | Сценарий | Функциональное требование | BR | Вес | Статус |
|---|---|---|---|---|---|
| S1: #FR1.3-1 | Пользователь запускает восстановление пароля | Интерфейс открывает экран восстановления, показывает поле Email или телефон, действие Продолжить и ссылку Я не помню данные или нет к ним доступа; продолжение недоступно до ввода данных. | 1 | Частично, #OQ1.3-2 | |
| S2: #FR1.3-2 | Пользователь указывает телефон для восстановления | Интерфейс после ввода телефона отправляет код на почту, показывает замаскированный email и таймер Новый код через 0:59. После истечения первого таймера интерфейс позволяет отправить второй код на почту; только после истечения таймера второго кода становится доступно действие Отправить код по смс. На SMS-шаге отображается указанный пользователем телефон без маскирования. | 1 | Частично, #OQ1.3-3 | |
| S2: #FR1.3-3 | Пользователь указывает email для восстановления | Интерфейс после ввода email отправляет код на указанную почту, показывает email в сообщении о письме и таймер Новый код через 0:59. После истечения первого таймера интерфейс позволяет отправить второй код на почту; только после истечения таймера второго кода становится доступно действие Отправить код по смс. SMS используется только как третья попытка для экономии бюджета компании; на SMS-шаге отображается замаскированный телефон. | 1 | Частично, #OQ1.3-3 | |
| S3: #FR1.3-4 | Пользователь подтверждает восстановление и задает новый пароль | Интерфейс принимает код из почты или SMS, после успешного подтверждения открывает поля Пароль и Повторите пароль, позволяет показать или скрыть введенные значения и сохранить новый пароль действием Сохранить; после успешного сохранения пользователь переходит к входу. | 1 | Реализовано | |
| S4: #FR1.3-5 | Пользователь не помнит данные или не имеет к ним доступа | Интерфейс открывает экран Контактные данные для обратной связи, принимает email или телефон для связи, отправляет обращение и показывает подтверждение Ваш запрос отправлен в службу поддержки. С вами свяжутся в ближайшее время с действием Хорошо. | 2 | Реализовано | |
| S4: #FR1.3-6 | Пользователь сталкивается с ошибкой поиска аккаунта или ввода SMS-кода | Интерфейс показывает ошибку в текущем контексте восстановления: Пользователь с данным телефоном не найден, Пользователь с данной почтой не найден или ошибку ввода SMS-кода. При неверном SMS-коде интерфейс показывает состояние ошибки в поле кода и таймер Новый код через 0:59; после истечения таймера позволяет выполнить действие Отправить новый код. Если код введен неверно больше 3 раз, интерфейс показывает сообщение Слишком много попыток. Новый код через 59:59 и возвращает пользователя к экрану ввода SMS-кода после истечения часа. | 2 | Частично, #OQ1.3-4 | |
| S4: #FR1.3-7 | Пользователь неверно вводит новый пароль | Интерфейс показывает ошибку под полями Пароль и Повторите пароль и не позволяет продолжить, если пароль недопустим: больше 64 символов, меньше 8 символов, содержит недопустимые символы, например +=, или не содержит хотя бы 1 заглавную букву, 1 цифру и спецсимвол. | 2 | Частично, #OQ1.3-5 |
6. Открытые вопросы
BRD 1.3 v0.1 · musbooking_personal_account · commit cdfa1dad1874864b3317ce7cb4e989f7e6ed6e5d / origin/main (2026-09-07) · 2026-09-08 · повторная сверка по итогам дейликов · якорь:
features.fsd/auth-password-recovery/,features.fsd/auth-access-recovery/,pages/auth/password-recovery.vue,pages/auth/access-recovery.vue,server/api/auth/send-restore-password-code-partner.post.ts,server/api/auth/validate-restore-password-partner.post.ts,server/api/auth/set-new-password.post.ts,server/api/auth/restore-password-support.post.ts,shared.fsd/api/auth/,shared.fsd/validation-schemes/auth-schemes.tsСводка: новых вопросов 4 (все Open, все Разработка; из них 2 по требованиям веса 1) · существующих открытых вопросов не тронуто: 1 (#OQ1.3-1 — пустая строка в исходнике, дописаны только недостающие колонки) · статусов изменено: 7 из 7 (были пустые) · обратный проход: без отдельных находок сверх покрытых вопросами выше Маршрутизация без сверки с гайдбуком (гайдбук не передан).
| ID | Источник | Вопрос | Кому | Статус | Рекомендации | Итоговое решение |
|---|---|---|---|---|---|---|
| #OQ1.3-1 | ||||||
| #OQ1.3-2 | Код FR1.3-1 | Требование говорит: продолжение на экране восстановления недоступно до ввода данных. В коде кнопка Продолжить блокируется только на время отправки запроса, а не по пустоте поля Email или телефон — нажать её можно и с пустым полем, ошибка появится только после попытки отправки. \ features.fsd/auth-password-recovery/ui/PasswordRecoveryIdentifierForm.vue:67-74 | Разработка | Open | Завести тикет в Bitrix: завязать disabled кнопки Продолжить на заполненность/валидность поля идентификатора. | |
| #OQ1.3-3 | Код FR1.3-2, FR1.3-3 | Требование говорит: сценарий восстановления зависит от того, с чего начал пользователь — с телефона или с email: код сперва всегда уходит на почту, при повторе — снова на почту, и только после второго таймера открывается кнопка Отправить код по смс; при этом телефон на SMS-шаге показывается замаскированным или нет в зависимости от того, с чего пользователь начал. В коде такого разделения на фронте нет: и для «начал с телефона», и для «начал с email» вызывается один и тот же метод повторной отправки с тем же идентификатором, который ввёл пользователь; какой канал использовать (email или SMS) и как маскировать контакт решает исключительно бэкенд по значению passwordResetCodeSendState/maskedContact в ответе. Кнопка повторной отправки всегда называется Отправить новый код, текста Отправить код по смс в коде нет. \ features.fsd/auth-password-recovery/ui/PasswordRecovery.vue:120-132,175-188; features.fsd/auth-password-recovery/ui/PasswordRecoveryCodeForm.vue:78-85 | Разработка | Open | Проверить на бэке (IdentityService), действительно ли текущая реализация выдерживает каскад «email → повтор email → SMS» и правило маскирования по сценарию, описанные в требовании — фронт лишь показывает то, что возвращает бэк, и не отвечает за эту логику сам по себе; при подтверждении со стороны бэка — обновить текст кнопки на Отправить код по смс, когда бэк переключил канал на SMS. | |
| #OQ1.3-4 | Код FR1.3-6 | Требование говорит: ошибка поиска аккаунта различается по каналу (Пользователь с данным телефоном не найден / Пользователь с данной почтой не найден), а после 3 неверных попыток ввода SMS-кода показывается Слишком много попыток. Новый код через 59:59 с возвратом к экрану кода через час. В коде для отсутствия аккаунта используется один и тот же общий текст Аккаунт не найден независимо от канала; счётчика из 3 попыток и отдельного часового таймера на фронте нет — текст Слишком много запросов показывается напрямую по коду ответа бэка, без клиентской логики подсчёта попыток и без текста 59:59. \ shared.fsd/lib/errors-text/errorsText.ts:17-18; features.fsd/auth-password-recovery/lib/parseError.ts:8-19 | Разработка | Open | Завести тикет в Bitrix: развести тексты ошибки «аккаунт не найден» по каналу (телефон/почта) и согласовать с бэком контракт для отдельного состояния «слишком много попыток» с текстом и таймером 59:59, как в требовании — сейчас на фронте для этого нет ни текста, ни счётчика попыток. | |
| #OQ1.3-5 | Код FR1.3-7 | Требование говорит: пароль не должен содержать недопустимые символы, например +=, и обязан содержать заглавную букву, цифру и спецсимвол. В коде символы + и = не запрещены — наоборот, любой символ, который не буква и не цифра (включая + и =), засчитывается как обязательный «спецсимвол». Дополнительно код запрещает кириллицу и пробелы в пароле — эти два правила в тексте требования не упомянуты. \ shared.fsd/validation-schemes/auth-schemes.ts:31-40 | Разработка | Open | (А, рекомендуется) уточнить у бизнеса реальный список запрещённых символов пароля (сейчас += в тексте требования выглядит как пример, а не буквальный список) и привести код и формулировку BRD к одному правилу; заодно решить, оставлять ли запрет кириллицы/пробелов — этого нет в тексте требования. (Б) если текущая реализация (любой спецсимвол разрешён, включая +=) устраивает бизнес — просто уточнить формулировку BRD. |