IT-инфраструктура для бизнеса и творчества
Разработка
Pavel Sherer

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

Создаём удобную, безопасную и архитектурно грамотную регистрацию через 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-проектов, и все свои материалы агрегирую в уютном телеграм-канале, велкам.

{ "author_name": "Pavel Sherer", "author_type": "self", "tags": ["\u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044f","selectel_\u0438\u043d\u0441\u0442\u0440\u0443\u043a\u0446\u0438\u044f"], "comments": 40, "likes": 51, "favorites": 284, "is_advertisement": false, "subsite_label": "dev", "id": 156552, "is_wide": true, "is_ugc": true, "date": "Thu, 10 Sep 2020 21:55:04 +0300", "is_special": false }
(function () { let cdnUrl = `https://specialsf378ef5-a.akamaihd.net/SelectelBranding/images/` let previousArticleNumber = null let currentArticleNumber = 0 let platform = 'Desktop' let articles = [ { name: 'camera', url: `${cdnUrl}CameraCat`, text: 'умную камеру для\u00A0наблюдения за\u00A0котиками', link: 'https://vc.ru/selectel/306690', num: 3 }, { name: 'chill', url: `${cdnUrl}ChillCat`, text: 'трекер, который подскажет, когда пора отдохнуть', link: 'https://vc.ru/promo/288561-eye-tracker', num: 1 }, { name: 'cloud', url: `${cdnUrl}CloudCat`, text: 'котика: даёшь ему «пять», а\u00A0он делает бэкап в облако', link: 'https://vc.ru/dev/294799-maneki-neko', num: 2 } ] let buttonCycle = document.querySelector('.button--cycle') let buttonChoose = document.querySelector('.button--choose') let buttonMobile = document.querySelector('.button--mobile') let textField = document.querySelector('.selectel-footer-subtitle') let imageAgent = document.querySelector('.image--agent') let banner = document.querySelector('.selectel-footer') buttonCycle.addEventListener('click', cycleClick) buttonChoose.addEventListener('click', () => sendEvent(`Promo ${articles[currentArticleNumber].num} Left`, 'Click')) buttonMobile.addEventListener('click', () => sendEvent(`Promo ${articles[currentArticleNumber].num} Left`, 'Click')) let media = window.matchMedia("(max-width: 570px)") media.addEventListener('change', matchMedia) function matchMedia() { if (media.matches) { platform = 'Mobile' } else { platform = 'Desktop' } update() } matchMedia() function cycleClick(event) { sendEvent(`Promo ${articles[currentArticleNumber].num} Right`, 'Click') if (event) { event.preventDefault() event.stopPropagation() } window.open('https://vc.ru/tag/selectelDIY', '_blank') //cycle(event) } function cycle(event) { // incrementArticleNumber() textField.innerHTML = generatedText() imageAgent.src = articles[currentArticleNumber].url + platform + '.svg?3' imageAgent.setAttribute("class", "") imageAgent.classList.add('image--agent', articles[currentArticleNumber].name) banner.href = articles[currentArticleNumber].link } function update() { banner.href = articles[currentArticleNumber].link imageAgent.src = articles[currentArticleNumber].url + platform + '.svg' textField.innerHTML = generatedText() } function incrementArticleNumber() { previousArticleNumber = currentArticleNumber if (currentArticleNumber >= articles.length - 1) { currentArticleNumber = 0 } else { currentArticleNumber++ } } const sendEvent = (label, action = 'Click') => { const value = `SelectelDIY — loc: Footer — ${label} — ${action}`; if (window.dataLayer !== undefined) { window.dataLayer.push({ event: 'data_event', data_description: value, }); } }; function generatedText() { let defaultText if (platform === 'Desktop') { defaultText = `Мы тут собрали %text%. Хотите научим?` } else { defaultText = `Мы тут собрали %text%.` } return defaultText.replace('%text%', articles[currentArticleNumber].text) } function getRandom(min, max) { min = Math.ceil(min) max = Math.floor(max) return Math.floor(Math.random() * (max - min + 1)) + min } (function create() { currentArticleNumber = getRandom(0, articles.length - 1) cycle() let page = document.querySelector('.page--entry') if (page) { function insertAfter() { let parents = page.querySelectorAll('[data-id="7"]') let referenceNode = parents[0] referenceNode.parentNode.insertBefore(banner, referenceNode.nextSibling); loaded() } setTimeout(() => insertAfter(), 0) } }()) function loaded() { banner.classList.add('loaded') } loadImages([ `${cdnUrl}CameraCatDesktop.svg`, `${cdnUrl}ChillCatDesktop.svg`, `${cdnUrl}CloudCatDesktop.svg`, `${cdnUrl}CameraCatMobile.svg`, `${cdnUrl}ChillCatMobile.svg`, `${cdnUrl}CloudCatMobile.svg?3`, ]) function loadImages(urls) { return Promise.all(urls.map(function (url) { return new Promise(function (resolve) { var img = document.createElement('img'); img.onload = resolve; img.onerror = resolve; img.src = url; }); })); } }())
0
40 комментариев
Популярные
По порядку
Написать комментарий...

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

6

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

9

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

5

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

9

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

–6

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

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

9

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

–8

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

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

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

8

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

–9

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

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

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

7

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

–11

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

11

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

–12

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

2

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

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

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

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

1

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

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

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

1

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

1

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

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

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

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

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

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

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

2

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

1

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

1

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

0

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

3

Спасибо.

0

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

1

Пожалуйста)

0

Email дёшево и базово, телефон эффективнее, к примеру Продажа товаров в интернет магазине с телефонной авторизацией лучше, когда у части пользователей нет email (не помнят) телефонная регистрация авторизация идеальна

0

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

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

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

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

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

2

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

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

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

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

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

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

3

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

0

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

1

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

0

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

1

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

0

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

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

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

0

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

0

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

0

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

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

0

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

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

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

–1

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

0

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

0
Читать все 40 комментариев
«Сбер» научил свой ИИ-сервис определять возможные признаки рака на ранних стадиях по снимкам лёгких Статьи редакции

Это может помочь врачам при диагностике заболевания.

Travers – поиск инструкторов по активным видам спорта

Мы сделали второе приложение, раскатили сервис на всю Россию и изменили бизнес-модель. Многое благодаря пользователям vc.ru!

Курс доллара упал ниже 70 рублей впервые с лета 2020 года после повышения ключевой ставки Статьи редакции

Евро подешевел до 81,3 рубля впервые за год.

Как не попасть в карьерную ловушку тимлида: личный опыт

Кажется, что тимлиду просто некуда расти: дальше надо либо идти в менеджмент, либо наоборот, становиться узконаправленным разработчиком. По просьбе «Лаборатории Касперского» Евгений Мацюк, который прошел в компании неординарный путь, рассказал о своих карьерных развилках во время и после тимлидства, а также поделился опытом горизонтального роста.

Исследование: сотрудники хотели бы иметь комнату отдыха, бесплатный сок, а работодатели уже готовы покупать ЗОЖ-снеки

Онлайн-сервис доставки продуктов и товаров СберМаркет и исследовательское агентство Research Me спросили сотрудников, как они хотели бы питаться в офисе и что в нем видеть. В опросе приняли участие более 1500 работающих людей по всей России. Сервис также спросил работодателей – В2В-клиентов СберМаркета: что они покупают в офис, что точно никогда…

Шпаргалка для инвестора: сделки РЕПО

Рассказываем об одном из важнейших инструментов рынка ценных бумаг — сделках РЕПО.

Дизайн-джем #42: мифы и легенды о русалках, японские рассказы, космические приключения и азы точных наук

В красочном дайджесте, посвящённом детским книжным иллюстрациям, от Futura by red_mad_robot.

«Яндекс.Маркет»: в моем заказе вместо наушников оказалась бутылка из-под водки

Я давно хотела беспроводные наушники и наконец заказала себе Apple AirPods. Оформила заказ 15.10.2021 через Яндекс.Маркет в магазине Superbia.ru

#20вопросов Ивану Юнину, директору проекта "Транспортные инновации Москвы"

Транспортная отрасль сегодня претерпевает колоссальные изменения, во многом благодаря инновациям. Стартапы с технологиями на базе AI для транспортной сферы востребованы как никогда. Согласно отчету Deloitte "Transporattion Trends 2020" глобальный рынок AI для транспортной отрасли к 2023 году может достигнуть 3,5 млрд долларов США.

ПСБ запустил личный кабинет для предпринимателей. Там можно следить онлайн за каждым своим терминалом Статьи редакции

Сервис предоставляется бесплатно.

Где сделать сайт бесплатно: обзор тарифов конструкторов 2021

Разберем цены и условия самых популярных конструкторов сайтов.

null