Конкурс инструкций

Инструкция: как написать идеальную регистрацию

Создаём удобную, безопасную и архитектурно грамотную регистрацию через email и соцсети. Ну и логин с восстановлением доступа, конечно.

Небольшое вступление

Регистрация является неотъемлемой частью большинства цифровых продуктов. Мы постоянно заводим новые аккаунты, придумываем сложные (или нет) пароли, у многих даже есть специальная почта для этих нужд.

Однако давайте вспомним, как часто мы встречали идеальную регистрацию? Почему даже крутые компании не могут сделать удобную и безопасную систему логина и восстановления доступа? Кажется, что все продуктовые дизайнеры настолько свыклись с тем, что регистрация — это просто, что даже не прилагают особенных усилий для её проектирования.

Простой пример. Кто из нас не сталкивался с тем, что тупит перед формой входа, не помня, как именно он регался на этом сервисе: через почту или какую-то из соцсетей? И таких примеров тьма. Но самое грустное в том, что мы сами считаем это нормой, и чаще всего виним себя и свою забывчивость, тогда как чаще всего виноват в этом именно сервис.

Я решил написать подробную инструкцию без привязки к конкретному языку программирования или методологии проектирования. Чистая логика, которую каждый без труда сможет подогнать под себя и реалии своего проекта.

Опыт в разработке и продуктовом дизайне тут тоже не особенно важен: начинающие могут использовать эту статью в качестве пошагового руководства; опытные же, возможно, почерпнут из неё какие-то отдельные удачные решения.

Оглавление

1. Концепция

1.1. Задача

Реализовать схему регистрации, аутентификации и восстановления доступа посредством email и соцсетей.

Из-за универсальности инструкции, не допускается привязка к конкретным фреймоворкам, базам данных или программным решениям.

Кроме того, в схеме не реализована двойная аутентификация, так как она предполагает определённые технические решения (например, TOTP или SMS), которые также могут быть продиктованы особенностями продукта или бизнес-логики.

1.2. Формат

Инструкция представлена в виде набора сценарных схем с пояснениями. Отдельно описываются сложные или не очевидные сценарные моменты.

Каждый экран, используемый в схемах, имеет своё название и состояние. Состояние может определять внешний вид или логические особенности (например, состояние «ValidationError» подразумевает сообщения об ошибках валидации формы).

Легенда для схем, используемых в инструкции (SVG)

Каждый серый (клиент) и синий (сервер) блок является функцией разрабатываемой системы. Такие функции не описываются отдельно, так как их реализация может зависеть от особенностей конкретного языка или программного окружения.

Важное значение имеют соединительные линии (стрелки) на схемах. Они могут быть двух видов: сплошные (переходы) и пунктирные (обмен данными). На основании пунктирных линий можно, например, спроектировать API.

2. Регистрация через email

Регистрация пользователя через email осуществляется в два этапа:

  1. заполнение формы регистрации;
  2. подтверждение email.

Поля, заполняемые пользователем при регистрации, могут быть произвольными. Однако в их числе обязательно должны быть поля «email» и «пароль»: первое используется как универсальный идентификатор, второе косвенно определяет тип регистрации (при регистрации через соцсети пароль не создаётся).

2.1. Заполнение формы

Наличие аккаунта

При регистрации через email, проводится проверка на наличие почты в базе данных. Если пользователь с таким email уже зарегистрирован, то происходит передача управления процессом общей функции «проверка на привязанные соцсети».

Временный аккаунт

До того, как пользователь не подтвердил свой email, его аккаунт является временным. Это позволяет:

  • более гибко управлять правами доступа (например, таким пользователям можно ограничить набор разрешённых действий);
  • автоматически очищать базу от неактивированных аккаунтов (например, по прошествии определённого времени).

В базе данных временный аккаунт может отличаться от обычного простым булевым флагом — или же такие аккаунты могут вообще храниться в отдельной таблице.

Схема регистрации через email (SVG)

2.2. Подтверждение

Подтверждение email классическое: ссылка с GET-параметрами в письме.

Срок жизни подтверждающей ссылки

В случае, если в вашем сервисе работает «очистка» БД от неактивных аккаунтов, разумно установить срок жизни подтверждающей ссылки, который будет несколько меньше, чем период присутствия временных аккаунтов в базе. Это исключит ошибки, когда пользователь пытается подтвердить почту, а его временный аккаунт уже удалён.

Повторное подтверждение

В ряде случаев имеет смысл обрабатывать повторный переход по подтверждающей ссылке, и показывать пользователю сообщение «email уже подтверждён». Этого нет в схеме, так как автор однажды столкнулся со злоупотреблением подобной функциональностью. Однако если вы уверены, что для вашего продукта это не проблема — рекомендую реализовать.

Схема подтверждения email после регистрации (SVG)

3. Регистрация и логин через соцсети

При использовании соцсетей схема регистрации во многом использует те же механизмы, что и логин — поэтому здесь они объединены.

Соцсеть не вернула email

Если соцсеть не вернула email, система создаёт временный аккаунт без email. После этого пользователь должен ввести свою почту в специальном окне. После ввода email, проверяется его наличие в базе данных.

Если пользователь с таким email уже зарегистрирован, то происходит передача управления процессом общей функции «проверка на привязанные соцсети».

Если пользователя с таким email нет в базе данных, запускается стандартная процедура отправки подтверждающего письма (описана в разделе «регистрация -> подтверждение»).

Объединение аккаунтов

Если пользователь с email, который вернула соцсеть, уже зарегистрирован в системе, то проводится проверка на соответствие прикреплённой к его аккаунту соцсети.

Если соцсеть та же, которую использует пользователь в настоящий момент, то пользователь успешно аутентифицируется (общие функции «запись успешного входа» на сервере и «успешная аутентификация» на клиенте).

Если соцсеть отличается от той, которую использует в настоящий момент пользователь, или пользователь был зарегистрирован с помощью email, то к существующему аккаунту добавляется текущая соцсеть, и уже тогда происходит успешная аутентификация (аналогично случаю выше).

Таким образом, при соответствии email, у пользователя не дублируются аккаунты, а сервис получает больше статистической информации о своих пользователях.

Схема регистрации через соцсети (SVG)

4. Логин (аутентификация)

Механика логина максимально простая: пользователь вводит email и пароль, после чего сервер проверяет их на соответствие.

Шифрование

Крайне рекомендуется хранить пароли в БД в хэшированном виде (не MD5), использовать дополнительные «соли» для лучшей безопасности (спасибо Saucedo Puetz за поправку в комментариях).

Защита от брутфорса

Способ защиты от перебора часто связан с конкретным программным решением или библиотекой, которую вы используете. Могут учитываться сессии, куки, ip-адреса, вспомогательные факторы (вроде включенного JS) и многое другое. Не забывайте про защиту от перебора, это важно.

Схема аутентификации (SVG)

5. Восстановление доступа

Восстановление доступа к аккаунту осуществляется в два этапа:

  1. заполнение формы восстановления;
  2. подтверждение: переход из письма и ввод нового пароля.

5.1. Заполнение формы

Подстановка email

Если пользователь в рамках текущей сессии уже вводил email в формах регистрации или логина, то при переходе к восстановлению доступа, соответствующее поле предзаполняется.

Отсутствие пароля

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

Если система обнаруживает отсутствие пароля в профиле, она проверяет, к какой соцсети привязан пользователь, и затем предлагает ему войти через эту соцсеть. Если же соцсеть по какой-то причине не была обнаружена, то запускается стандартная процедура отправки email со ссылкой на ввод нового пароля.

Схема восстановления доступа (SVG)

5.2. Подтверждение

Срок жизни подтверждающей ссылки

Крайне желательно, чтобы ссылка на смену пароля не была «вечной». Это позволит избежать множество неприятных ситуаций. Поэтому при проверке ссылки на сервере мы, в числе прочего, проверяем и её срок действия.

Однако для усложнения жизни злоумышленникам мы не будем показывать конкретное сообщение об «устаревшей» ссылке, указав просто на общую ошибку «неверная ссылка». Однако иногда это может создать неудобство для пользователей. В общем, на ваше усмотрение — безопасность или удобство, вечный конфликт.

Деактивация подтверждающей ссылки

Ну и разумеется, мы не можем позволять пользователям несколько раз сбрасывать пароль по одной и той же ссылке (банальный перехват URL позволит вытворять непозволительные вещи). Поэтому после первого перехода из письма ссылка будет деактивироваться.

В принципе, можно вообще удалять её из базы данных, но тогда будет сложнее отслеживать потенциально взломанных пользователей. Впрочем, это тема отдельной статьи.

Автологин

После перехода по ссылке из письма мы не будем заставлять наших пользователей заново входить в аккаунт. Сам факт доступа к почте с возможностью последующей смены пароля упраздняет необходимость введения дополнительных мер безопасности в виде логина. Поэтому аутентификация происходит автоматически, как только был проверен ключ из ссылки.

Дополнительно, вы можете реализовать механизм принудительной смены пароля (чтобы после логина не перенаправлять пользователя в аккаунт, например). Но это уже на ваш вкус и реалии продукта.

Схема подтверждения сброса пароля через email (SVG)

6. Общие функции

Для упрощения архитектуры в этот раздел вынесены функции, которые используются более одного раза в системе. Их можно реализовать отдельно и обращаться к ним по мере необходимости. Удобно, быстро и сильно стабилизирует как саму разработку, так и поддержку продукта.

6.1. Клиент

Показ сообщений

Тут всё просто. В зависимости от особенностей интерфейса, вы можете реализовать показ сообщений об ошибках валидации форм, ответов сервера и прочих событиях.

Валидация

Тоже не сложно. Как правило, типов полей форм, которые надо валидировать, максимум 3-4, плюс один кастомный, по маске (RegExp). Логично вынести валидацию в отдельную функцию и применять к конкретным полям по необходимости. Благо, для любого фреймворка есть куча готовых решений на эту тему.

Отправка данных

Стандартный механизм асинхронной отправки с обработкой результата. Как правило, имеется в любом фреймворке «из коробки», но иногда имеет смысл расширить функциональность (например, за счёт URL’ов API, помещённых в константы).

Успешная аутентификация

Функция успешного логина. Подразумевает последующее перенаправление на целевую страницу. В схеме целевая страница представлена профилем с дефолтным состоянием (Nav.Profile, Default), однако хорошим тоном считается запоминать URL, с которого был вызван логин, и возвращать на него пользователя после успешной аутентификации.

Подсказка по логину через соцсети

Иллюстрация решения проблемы из начала статьи (когда пользователь не может вспомнить, через какую соцсеть он входил).

Если у пользователя истёк срок жизни сессии, но в браузере сохранились куки соцсетей, вы можете дать ему простую подсказку — например, подсветить нужную соцсеть. Или даже вывести рядом с кнопкой соцсети его аватар.

Эта функция может быть вызвана везде, где есть необходимость регистрации или логина (на отдельных страницах, в форме комментариев и тп), однако её программная реализация может зависеть от механик авторизации конкретной соцсети или сервиса.

6.2. Сервер

Очистка данных

Любые данные, попадающие на сервер из клиента (и не только), должны быть в обязательном порядке очищены от всякой гадости, вроде SQL-инъекций или неприятных штук вроде XSS. Это действительно важно, потому что потом может сказаться на жизнеспособности всего продукта и безопасности данных его пользователей.

Валидация

Аналогично функции на клиенте, можно написать отдельную функцию валидации данных на сервере, которая будет принимать в качестве параметров сами данные и тип валидации (включая регулярные выражения). Вызывать такую функцию можно буквально в пару строк.

Отправка email

Для многих языков и фреймворков есть готовые нативные решения по отправке email (в том числе, с помощью SMTP). Так как письма могут отправляться из многих частей продукта, логично использовать для этого единую функцию.

Запись успешного входа

Очень часто нужно отслеживать активные сессии пользователя или сообщать ему о новых логинах. Для этого как минимум потребуется фиксировать все случаи успешной аутентификации. Можно записывать их в БД или вести отдельный лог — как вам удобнее.

Проверка на привязанные соцсети

Функция вызывается в результате проверки наличия email в базе данных. Если пользователь с таким email уже зарегистрирован, то происходит проверка на наличие привязанных соцсетей. В зависимости от результата проверки пользователю предлагается войти через соцсеть (если найдена привязанная) или с помощью почты и пароля.

7. Итоговая схема

Абсолютно нечитаемая (особенно в рамках сайта), но исчерпывающая схема всего того, то было описано в этой статье. Может пригодиться архитекторам, которые хотели бы выявить дополнительные общие функции или оценить объём предстоящих работ.

Общая схема регистрации, логина и восстановления доступа (SVG)

В завершение

Если вы нашли в изложенных схемах недостатки или у вас есть замечания по UX-составляющей, я буду искренне признателен за сообщение о таких случаях в комментариях. Давайте вместе сделаем этот мир капельку лучше — хотя бы в плане такого частого кейса, как регистрация.

Я много пишу про проектирование, разработку и продюсирование IT-проектов, и все свои материалы агрегирую в уютном телеграм-канале, велкам.

0
40 комментариев
Написать комментарий...
Владимир Воробьев

Развели тут хабр 

Ответить
Развернуть ветку
Тофсла, Вифсла и партнёры

При том не просто хабр, а хабр-торт!

Ответить
Развернуть ветку
Montana

Боги сошли с небес и детально написали ТЗ

Ответить
Развернуть ветку
Василий Туркин

Отлично, спасибо большое за инструкцию! То, что надо!

Ответить
Развернуть ветку
Saucedo Puetz

С точки зрения безопасности использовать для идентификации email. идентификация должна быть по логину а email всегда скрыт.
И да, пароли не шифруются а хэшируются!

Ответить
Развернуть ветку
Pavel Sherer
Автор

Насчёт email спорно. Во-первых, логин — это неудобно, все привыкли вводить почты. Во-вторых, email нигде, кроме восстановления, можно и не светить. Да и там, при необходимости, можно повесить защиту от перебора.

Касаемо хэширования да, согласен, запарился. Исправил в статье.

Ответить
Развернуть ветку
Saucedo Puetz

Вы поймите что безопасность и "удобно", быстро и не согласуются между собой. Удобно вам-удобно атакующему. Быстро вам-быстро и атакующему.
email как минимум светится каждый раз когда человек логиниться на ваш сайт, а значит и во всяких запоминалках логинов. Для безопасности пользователя важно важно минимизировать засветку email как только можно.

Ответить
Развернуть ветку
Pavel Sherer
Автор

Я это прекрасно понимаю, не первый год в индустрии. Однако любой цифровой сервис или продукт, если хочет быть успешным, вынужден балансировать между безопасностью и удобством. Вы можете быть максимально защищены, но какой в этом смысл, если конверсия в логин практически отрицательная, а пользователей у вас — полтора инвалида.

К сожалению (или к счастью), за создание цифровых продуктов отвечают не только одни разработчики и специалисты по цифровой безопасности. Два года назад я в рамках одного проекта проводил исследование: почту в качестве предпочтительной формы регистрации и входа выбрали более 80% респондентов. Предпочтя её и обычному логину, и номеру телефона.

Ну и напоследок. Почта — не самая чувствительная часть персональных данных. Если речь идёт о взломах условных "запоминалок логинов", то там вообще другого уровня проблемы.

Ответить
Развернуть ветку
Saucedo Puetz

Я вас понял, вы как и многие к сожалению побежали по популярной в последнее время дорожке-делать то что хотят пользователи. Только вот в опросе вы забыли упомянуть что риски компреметации аккаунта повышаются, если использовать почту как средство идентификации. И сколько % пользователей после этого все еще выбрали бы почту? Более того-в случае компрометации аккаунта кто будет у пользователя виноват? Он сам думаете? Я думаю пользователь будет обвинять именно вас, и кстати весьма обосновано.

Ответить
Развернуть ветку
Pavel Sherer
Автор

А расскажите, пожалуйста, как повышаются риски компрометации аккаунта, если пользователь использует почту, а не логин? Посредством социнженерии? В 99% случаев нет разницы, email или логин вытаскивать из доверчивых пользователей или из их скомпрометированных устройств.

И да, я, как вы выразились, "побежал по популярной дорожке" удобства пользователей. Почти все цифровые продукты — это бизнес. В наше время невозможно сделать продукт успешным, если он неудобен пользователям. А без успешности у него не будет денег. А без денег нечем будет платить разработчикам и прочим членам проектной команды. Как итог: если продукты не будут удобными, то такие "борцы", как вы, останетесь без работы.

И заметьте, я не призываю полностью отказываться от безопасности или даже серьёзно её снижать. Перечитайте статью.

Ответить
Развернуть ветку
Saucedo Puetz

В случае если для идентификации используется почта, атакующему нужно ее узнать. В случае если для идентификации используется логин, атакующему нужно узнать и логин и почту.
По поводу бизнеса-я так понял вы не особо паритесь насчет рисков информационной безопасности, впрочем как и многие ныне действуют по принципу срубить денег и свалить. Если это ваш путь-наздоровье, но не поминайте пожалуйста тогда информационную безопасность всуе

Ответить
Развернуть ветку
Pavel Sherer
Автор

Первая часть вашего ответа спорная в сценарной области. Вторая же просто не обоснована и даже оскорбительна. Думаю, разговор закончен, всего доброго.

Ответить
Развернуть ветку
Saucedo Puetz

Спасибо, с вами все ясно

Ответить
Развернуть ветку
Павел Киященко

Инструкция огонь. Делали подобные вещи для проекта реши-пиши с нуля и до всего из статьи доходили со временем ;-) Прочитать бы раньше... Но ещё будем прикручивать соцсети, так что обязательно перечитаю и сделаю подсказки через какую соц сеть логинились, если сессия пропала и в куках помним. Так просто и удобно!

Ответить
Развернуть ветку
Антон Смуров
Если соцсеть не вернула email, система создаёт временный аккаунт без email. После этого пользователь должен ввести свою почту в специальном окне. После ввода email, проверяется его наличие в базе данных.
Если пользователь с таким email уже зарегистрирован, то происходит передача управления процессом общей функции «проверка на привязанные соцсети».
Если пользователя с таким email нет в базе данных, запускается стандартная процедура отправки подтверждающего письма (описана в разделе «регистрация -> подтверждение»).

Не очень понятно. Email вы запрашиваете у юзера обязательно, без него он не сможет начать пользоваться сайтом? Если так, то это большой косяк на пути конверсии. А если ввод email может быть отложен, получится, что пользователь может произвести какую-то активность, затем ввести email и вдруг окажется, что на этот email у него уже есть другой аккаунт. И тут, либо писать функционал объединения аккаунтов (в зависимости от сложности функционала, может быть просто или практически невозможно), либо оставлять за юзером право выбора, которым аккаунтом пользоваться, но у него уже не получится прикрепить соцсеть к первому аккаунту с email'ом или наоборот ввести свой email в аккаунт, зарегистрированный через соцсеть.

Ответить
Развернуть ветку
Pavel Sherer
Автор

Если пользователь пока не подтвердил email (или соцсеть его не вернула), то ему может быть доступна ограниченная функциональность (например, только просмотр). Блокировать или нет основную функциональность — это уже больше вопрос к основной механике продукта, как и объединение аккаунтов с разными email. 

Более того, история с объединением аккаунтов вообще общая и не относится напрямую к регистрации (например, соцсеть может вернуть другой email — и тогда для появления "условий задачи" даже не понадобится отложенное подтверждение).

В целом, ваш вопрос справедлив, но ответить "универсально" я на него не могу, всё очень сильно зависит от особенностей конкретного продукта. Если выкинуть из требований, указанных в начале статьи, обязательность подтверждённого email, то достаточно будет просто убрать пару веток из схем.

Ответить
Развернуть ветку
Рустем Хайруллин

Еще может быть реализован функционал прикрепления соцсетей к профилю, когда клиент уже зарегистрирован и авторизован.
И если в этот момент прикрепляемая новая соцсеть вернет другой емейл, непонятно, как поступить. Особенно, если уже есть другой профиль с таким емейлом.

Ответить
Развернуть ветку
Pavel Sherer
Автор

Клёвый вопрос, спасибо. Этот кейс выходит за рамки непосредственно регистрации, но решаем довольно просто.

1. Если пользователь авторизован, и он прикрепляет новую соцсеть, то сначала мы проверяем, вернула ли соцсеть email. Если email не возвращён или email соответствует текущему, просто прикрепляем соцсеть к аккаунту.

2. Если соцсеть вернула email, отличающийся от того, под которым зарегистрирован текущий пользователь, то у нас снова проверка: есть ли в базе зарегистрированный аккаунт с этим email. Если нет, то прикрепляем соцсеть к аккаунту. Плюс здесь мы можем вывести новый email как резервный, например — это уже зависит от конкретных механик продукта.

3. Если email, который вернула соцсеть, прикреплён к другому аккаунту, то мы проверяем, прикреплена ли текущая соцсеть к аккаунту-владельцу нового email. Если прикреплена, то отказываем текущему пользователю в прикреплении соцсети, ссылаясь на то, что аккаунт с таким email уже зарегистрирован. Этот шаг необязателен и подходит для сервисов с высоким уровнем предиктивной безопасности (финтех, например).

4. Если текущая соцсеть не прикреплена к аккаунту-владельцу нового email, то предлагаем объединить аккаунты. Для этого отправляем на новый email подтверждающее письмо, и ждём, пока пользователь пройдёт по ссылке/скопирует код и тп. В это время можем дополнительно уведомить аккаунт-владельца нового email: например, отправить в аккаунт уведомление о попытке прикреплении его соцсетки к другому профилю.

5. После подтверждения нового email объединяем аккаунты. Эта механика уже совсем индивидуальная для каждого проекта. Плюс, как и в шаге 2, можем из нового email сделать резервный.

Шаги 3 и 4 можно миксовать, в зависимости от особенностей продукта и целевой аудитории. Понятно, что этот алгоритм подойдёт далеко не всем, но его совершенно точно можно подпилить под себя.

Ответить
Развернуть ветку
Alex One

Супер годнота. Так структурировано подавать инфу не каждый может, вернее могут, но не все.

Ответить
Развернуть ветку
Pavel Sherer
Автор

Спасибо, я стараюсь

Ответить
Развернуть ветку
Евгений Батищев

Красиво (во всех смыслах). А в чем рисовали схему?

Ответить
Развернуть ветку
Pavel Sherer
Автор

Спасибо. Рисовал в diagrams.net (бывший draw.io).

Ответить
Развернуть ветку
Евгений Батищев

Спасибо.

Ответить
Развернуть ветку
Олег Духовный

Спасибо за великолепную статью

Ответить
Развернуть ветку
Pavel Sherer
Автор

Пожалуйста)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Pavel Sherer
Автор

Отчасти согласен. Например, подрастающее поколение email вообще использует редко. Однако есть и в обратную сторону доводы:

1. Пока что регистрация через номер телефона имеет в среднем меньшую конверсию, чем через email. Для того, чтобы запрашивать номер телефона, сервис должен быть либо напрямую связан с финансами (например, тот же интернет-магазин, которому пользователь уже доверил свои деньги), либо обладать высоким кредитом доверия у пользователей.

2. Стоимость SMS в среднем пара рублей. В зависимости от продукта, один пользователь может за месяц тратить от 1-ой до 6-ти SMS. При невысокой LTV это может здорово шарахнуть по юнит-экономике.

3. Маркетинг почему-то продолжает любить email даже в наши дни.

Однако в целом, вход через SMS часто удобнее, да.

Ответить
Развернуть ветку
Evil Pechenka

Телефон это проблема с безопасностью, т.к. почтовые службы защищены не в пример лучше и могут быть в любой юрисдикции.

И ещё проблемы со связью, не получаешь SMS — доступ потерян, вот недавно мой оператор решил мне не присылать SMS от одной компании — всё, неизвестно что делать.

Номера заканчивают действие, в РФ 3 месяца, почта нет.

Почта дешёво — SMS дорого.

Дать сервису почту не трудно, телефон — могут начать звонить, сольют в спам-базы. Психологически труднее.

Ну т.е. по всем параметрам почта лидирует. 

Ответить
Развернуть ветку
Виталий Иванов

Поздравляю с ноутбуком!
А можете все же порекомендовать фреймворки, где такая модель если не доступна из коробки, то может быть реализована без сильного перепиливания кода?

Ответить
Развернуть ветку
Pavel Sherer
Автор

Спасибо :) Если честно, готовых решений прям не встречал. Все проекты разные, на разных технологиях и с разными проектными подходами. Давно планировал написать такое на ноде и пхп, но вряд ли в ближайшее время дойдут руки.

Ответить
Развернуть ветку
Виталий Иванов

Вот и я тоже недавно искал что-то более-менее готовое и не нашёл)

Ответить
Развернуть ветку
Evgeny Safonov

Firebase Auth фактически все из коробки. Вопрос только с прикручиванием отечественных OAuth провайдеров. Есть готовые клиенты под веб, иос, андроид, серверные клиенты тоже имеются для работы с пользователями. Проблема только с РФ законодательством и хранением пес данных в США. Если бы были в Европе сервера хотя бы, то было бы проще.
При этом, кстати, 10 тысяч смс для аутентификации бесплатно. Хотя потом конечно дорого выходит. 6 центов если не в США (там 1 цент). Если проект не большой. То прям топ. 

Ответить
Развернуть ветку
Polietilena a

На сайте dnipro-m.ua идеальный UX регистрации и логина. Email убрали за ненадобностью и пользователи счастливы.

Ответить
Развернуть ветку
Владимир Прокошев

Здравствуйте, Павел! Спасибо большое за развернутую статью!

У меня вопрос по поводу автологина. Вы пишете: "Сам факт доступа к почте с возможностью последующей смены пароля упраздняет необходимость введения дополнительных мер безопасности в виде логина."

Что если пользователь переслал сообщение другу? В таком случае друг, перейдя по ссылке автоматически авторизуется. Можно использовать временный ключ, но что, если владелец аккаунта не перешел по ссылкам, а просто перенаправил сообщение другу? Как можно решить проблему с автологином в этом случае?

Ответить
Развернуть ветку
Pavel Sherer
Автор

Никак. Если пользователь переслал письмо с восстановлением доступа другому пользователю (или даже просто ссылку), то тут ничего не поделать. Социнженерию никто не отменял.

Ответить
Развернуть ветку
Владимир Прокошев

Маловероятно, что пользователь станет пересылать письмо с восстановлением доступа. Но вот, например, приветственное письмо или письма на статьи, в которых ссылки на них с token для автологина, могут и переслать. Может быть можно ограничить по времени token для ссылок данного письма и тогда будет хоть какая-то защита?

Ответить
Развернуть ветку
Pavel Sherer
Автор

Речь шла именно про автологин при переходе на восстановление доступа.

Кроме того, технически нет возможности отследить, из пересланного ли письма перешёл пользователь.

Ответить
Развернуть ветку
Владимир Прокошев

Невнимательно прочитал заголовок раздела. Извините за странные вопросы.

 Кроме того, технически нет возможности отследить, из пересланного ли письма перешёл пользователь.

Это понятно. Спасибо!

Ответить
Развернуть ветку
Nikita Matveev

Возможно так и задумывалось, но в схеме не отражен момент валидации до отправки формы. Там есть развилка «Заполнено корректно?» но перед ней по идее должна быть проверка, либо простенькая на клиенте, либо более подробная на сервере(например можно сразу проверять на отсутствие почты в базе)

Ответить
Развернуть ветку
Pavel Sherer
Автор

Шаг "заполнено корректно" и есть валидация данных на клиенте до отправки формы. И такая же валидация есть на сервере.

Ответить
Развернуть ветку
37 комментариев
Раскрывать всегда