Best practice для подтверждения мейла при регистрации?

Question

[WhatIsHTML]

Каков лучший поток подтверждения электронной почты для пользователя и для приложения?
Некоторые варианты:
A) Самый простой вариант, но не самый лучший.

1. Пользователь отправляет форму регистрации.
   
2. На бэкэнде я отправляю ссылку со случайным хэшем на электронную почту пользователя. Параллельно я сохраняю этого пользователя в db с полями active: false, и случайным хешем.
   
3. Пользователь проверил почту, кликнул на ссылку.
   
4. На бэкэнд я пытаюсь найти пользователя с хешем. Если пользователь найден в базе, меняю поле active на true.
   

Недостаток: что делать, если электронная почта не верна или произошла ошибка во время отправки? Я не могу адекватно отобразить ошибку пользователю.
B) Мы можем обрабатывать все ошибки и отображать их пользователю, но очень медленный вариант

1. Пользователь отправляет форму регистрации.
   
2. На бэкэнде прежде всего я сохраняю этого пользователя в бд, затем отправляю ссылку со случайным хэшем на электронную почту пользователя и если письмо отправлено без ошибок, только тогда я отправляю ответ на клиент.
   
   
3. Если произошла ошибка при отправке почты, я отправляю сообщение об ошибке пользователю, поэтому он знает, что письмо не отправлено.
   
4. Вероятно, мне нужно удалить этого пользователя из бд, если случилась ошибка, чтобы он мог заново отправить форму регистрации (мейл уникальный)
   

Недостаток: Медленный процесс регистрации, много запросов к бд
C) Лучший вариант, я думаю

1. Пользователь отправляет форму регистрации.
   
2. На бекенде я сохраняю пользователя в бд.
   
3. Если сохранился в бд, я отправляю ответ пользователю и параллельно с этим отправляю ссылку на почту
   
4. Пользователь получает ответ, если нет ошибок, перенаправляется на страницу, например. `/last-step` с текстом `проверьте вашу электронную почту...` Также на этой странице будет ссылка, которая позволит снова отправить подтверждение по электронной почте (например, каждые 3 минуты)
   

Вопрос №1. Как я могу распознать на бэкэнде, кто кликнул ссылку? Я так понимаю, что нужно хранить информацию на клиенте об этом пользователе. Где ее хранить? В куки? Насколько долго? В сессии?
Вопрос №2. Стоит ли ставить срок годности для этой ссылки? Если да, то что делать с юзерами, которые не подтвердили свой мейл. Удалять насовсем из бд?
UPD
Вопрос №3 Что если отправлять на почту не страшную хеш ссылку, а просто код из 6 цифр? А на отдельной странице просить ввести этот код.

Comments

[Philipp]

Есть еще страшный вариант - в регистрации поле только с Email. Письмо отправляется пользователю сразу. После перехода по ссылке предлагается создать пароль и т.д. В таком случае email всегда валиден.

Answer 1

[Алексей Ярков]

Ответ на Вопрос №1: оно вам надо? Если юзер просрал доступ к почте и оттуда кто-то левый пошел по ссылке, то это проблема юзера.
Ответ на Вопрос №2: определенно стоит ставить срок. Я, например, час-два ставлю. Если регистрируется нормальный юзер, то он сразу идет и подтверждает. А вот тем, кто вовремя не подтвердил, можете напомнить о себе через день-неделю-месяц, а потом удалить нафиг )))
UPD
Ответ на Вопрос №3: вполне приемлемо.

Comments

[WhatIsHTML]

1. Ну оно то так, но могут быть проблемы с самим сервисом, который отправляет почту. Например мейлган или nodemailer.

[Алексей Ярков]

WhatIsHTML: а как это с вопросом №1 связано?

[WhatIsHTML]

Алексей Ярков: хочу прояснить. Т.е. вариант С все таки годится, но если показывать ссылку "отправить письмо еще раз", то нужно знать, кто кликнул вот эту ссылку, чтобы знать кому ее отправлять. Вот в чем вопрос. Я думал, можно формировать токен на бекенде и хранить его в сессии где-то. Как вариант

[Алексей Ярков]

WhatIsHTML: геморрой. Лучше инпут для ввода мыла и кнопка "Отправить еще раз"

Answer 2

[Saboteur]

Лучший вариант №1.
Единственное, что можно поставить timestamp, и если пользователь не подтвердил почту в течение xx часов/дней, то зависит от ресурса - оставлять неподтвержденного пользователя, или не проводить регистрацию вообще и освобождать аккаунт для регистрации другого пользователя.

Если пользователь намеренно вводит нерабочую почту - это его проблемы.
Если ненамеренно вводит нерабочую почту - перерегистрируется, если что.

Answer 3

[d-stream]

Еще как вариант: держим пользователя до активации в черном теле, оставив ему собственно возможность править свой e-mail и отправлять активацию снова.

Ну и понятное дело - срок годности активации и ограничение на число и частоту смен почты и повторной активации.