На первый взгляд смена Email кажется вполне обыденной задачей. Но при ближайшем рассмотрении может возникнуть множество вопросов, в первую очередь связанных с безопасностью (особенно если Email используется в качестве обязательного поля для входа).
В этом посте я хочу поделиться нашим опытом проектирования этого сценария.
Важное примечание: в нашем сервисе пока не применяется двухфакторная аутентификация и Email является единственным обязательным идентификатором пользователя.
Распространённые причины смены Email
Причин для смены Email может быть не так много, но они достаточно весомые:
- Необходимость передать управление аккаунтом другому человеку. Например, корпоративный аккаунт в случае увольнения сотрудника должен быть передан другому менеджеру.
- Потеря доступа к старой почте.
- Желание пользователя изменить почту по другим причинам. Например, человек регистрировался на личную почту, чтобы протестировать продукт, а потом захотел перевести аккаунт на корпоративный адрес.
Задачи, которые стояли перед нами
- Дать пользователю возможность самостоятельно сменить Email.
- Снизить нагрузку на службу поддержки с просьбами о смене Email.
- Обеспечить определённый уровень безопасности, при котором злоумышленники не смогут завладеть чужим акаунтом.
Забегая вперед, сразу хочу сказать, что мы не рассматривали самый простой сценарий смены Email, когда пользователь без всякого подтверждения просто меняет свой адрес в настройках профиля. Так как в нашем случае это означало бы определенного рода уязвимости:
- Злоумышленник проник в чужой аккаунт → сменил Email → сменил пароль → восстановление пароля без Email невозможно…
- Пользователь ввёл неправильно Email → разлогинился → забыл пароль → восстановление пароля без Email невозможно…
Наконец сам процесс
После того, как пользователь нажал на кнопку Edit email, мы сразу запускаем процедуру редактирования. А именно, отправляем на старую почту клиента код подтверждения и показываем модалку с полем для ввода этого кода.
Сразу после того, как пользователь подтвердил свой старый Email, мы предлагаем ему ввести новый адрес. При этом предупреждаем, что новый адрес так же будет необходимо подтвердить
Как вы уже наверное догадались, следующим шагом необходимо подтвердить новую почту. Чтобы избежать прохождения всей процедуры с самого начала (в случае ввода неверного email адреса), на этом этапе можно откатиться на шаг назад, нажав кнопку Change, рядом с новой почтой.
Успех! Почта изменена. Показываем какой Email был и какой стал.
Ну и конечно не забываем про возможные состояния и ошибки (неверный код подтверждения, истекло время сессии, email уже зарегистрирован в сервисе).
Как вы могли заметить в нашем сценарии не обрабатывается кейс потери доступа к первоначальной почте, т.к. при смене Email необходимо подтвердить свой старый Email. Это сделано из соображений безопасности, описанных выше. Данный сценарий можно закрыть двухфакторной аутентификацией (например через СМС) или же, как в нашем случае, специальной процедурой идентификации пользователя специалистом поддержки.
У меня всё. Надеюсь данный паттерн кому-нибудь пригодится. Пишите, если есть чем дополнить.
