Инструкция: как написать идеальную регистрацию
Создаём удобную, безопасную и архитектурно грамотную регистрацию через email и соцсети. Ну и логин с восстановлением доступа, конечно.
Создаём удобную, безопасную и архитектурно грамотную регистрацию через email и соцсети. Ну и логин с восстановлением доступа, конечно.
Если соцсеть не вернула email, система создаёт временный аккаунт без email. После этого пользователь должен ввести свою почту в специальном окне. После ввода email, проверяется его наличие в базе данных.Если пользователь с таким email уже зарегистрирован, то происходит передача управления процессом общей функции «проверка на привязанные соцсети».Если пользователя с таким email нет в базе данных, запускается стандартная процедура отправки подтверждающего письма (описана в разделе «регистрация -> подтверждение»).Не очень понятно. Email вы запрашиваете у юзера обязательно, без него он не сможет начать пользоваться сайтом? Если так, то это большой косяк на пути конверсии. А если ввод email может быть отложен, получится, что пользователь может произвести какую-то активность, затем ввести email и вдруг окажется, что на этот email у него уже есть другой аккаунт. И тут, либо писать функционал объединения аккаунтов (в зависимости от сложности функционала, может быть просто или практически невозможно), либо оставлять за юзером право выбора, которым аккаунтом пользоваться, но у него уже не получится прикрепить соцсеть к первому аккаунту с email'ом или наоборот ввести свой email в аккаунт, зарегистрированный через соцсеть.
Если пользователь пока не подтвердил email (или соцсеть его не вернула), то ему может быть доступна ограниченная функциональность (например, только просмотр). Блокировать или нет основную функциональность — это уже больше вопрос к основной механике продукта, как и объединение аккаунтов с разными email.
Более того, история с объединением аккаунтов вообще общая и не относится напрямую к регистрации (например, соцсеть может вернуть другой email — и тогда для появления "условий задачи" даже не понадобится отложенное подтверждение).
В целом, ваш вопрос справедлив, но ответить "универсально" я на него не могу, всё очень сильно зависит от особенностей конкретного продукта. Если выкинуть из требований, указанных в начале статьи, обязательность подтверждённого email, то достаточно будет просто убрать пару веток из схем.