Как зарегистрироваться на сайте

Регистрация в интернете для новичков

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

Как же регистрироваться в интернете?

Для того, чтобы пройти регистрацию на сайте, нажмите на ссылку Регистрация. Она есть у всех сайтов, которые позволяют зарегистрироваться. Сама процедура регистрации на разных сайтах похожа, почти везде нужно указать логин, пароль и электронный адрес. Это наиболее часто встречаемые обязательные поля. Их нужно заполнять непременно. Могут быть и другие обязательные поля, как правило, они помечаются звездочкой или выделяются жирным. Также могут быть простые поля, которые вы можете заполнять по своему желанию. Очень часто в такие поля заносится информация о вашем городе, области, хобби, увлечениях и так далее. Рассмотрим для новичков основные поля регистрации.

Логин – это ваше будущее уникальное имя на сайте. Оно может состоять из русских, но чаще всего, из латинских букв и цифр. Например: petrov25. Если ваш регистрируемый логин уже занят другим человеком, то вам будет оповещение об этом и предложено изменить ваш логин. Логин не может повторяться у разных людей. Он должен быть свой и уникальный.

Пароль – Особое внимание уделите вашему паролю Не ставьте простые пароли, такие, как: 123456, petya или apteka2013. Такие пароли очень легко взломать и ваши данные могут попасть в руки не столь порядочных людей, которые могут ими воспользоваться. Наиболее безопасным паролем считается, которые состоит из латиницы (иными словами из английских букв алфавита) разного регистра (заглавных и прописных), цифр и специальных символов. Например: NyTr76%6^$aB Такой пароль считается более надежным. Старайтесь создавать пароли от 8 символов. Чем больше символов, чем пароль будет безопасным. На некоторых серьезных сайтах есть такой индикатор сложности пароля. При вводе символов в поле пароля, индикатор показывает степень сложности пароля: простой, средний, сложный. На других сайтах может быть генератор паролей на форме регистрации. Вам достаточно только нажать кнопку «Сгенерировать» и в поле автоматически ставится сгенерированный пароль, который вам нужно скопировать или запомнить. Если такого генератора нет, то вы сможете воспользоваться бесплатным расширением «Генератор паролей» для браузера Google Chrome. Для установки данного расширения, зайдите в Главное меню браузера (1) – Инструменты (2) – Расширения (3).

В открывшимся окне будут представлены все расширения, которые у вас есть в браузере. Спускаемся ниже и нажимаем на ссылку «Еще расширения»

После этого мы попадем в интернет-магазин Google, в верхнем левом углу в поле поиска вводим «Генератор паролей» и нажимаем клавишу Enter

Результаты поиска нам выдадут всевозможные Приложения и расширения с названием «Генератор паролей». Сначала будут показаны приложения. Спускаемся чуть ниже до раздела Расширения (1). Установим самое первое расширение Strong Password Generator (2). Для добавления данного расширения нажмите на кнопку «Бесплатно», которая сменится на «Проверка» (3), а вверху появится окно с предложением добавить данное расширение. Жмем на кнопку «Добавить» (4)

После добавление в верхнем правом углу окна браузера появится значок расширения (1), нажимаем на него.

На вкладке Generator в блоке 2 выбираем параметры для генерации пароля:

Lowercase letters – прописные буквы.

Uppercase letters – заглавные буквы.

Custom – специальные символы. В поле под ним вы сможете добавить другие специальные символы.

Length – длина пароля. В нашем случае пароль будет состоять из 10 символов. Если поставить галочку Random (3), то длина пароля будет произвольной длины.

Когда выбрали параметры, нажимаем на кнопку Generate (4) и мы видим наш сгенерированный пароль, который можно быстро скопировать, нажав на кнопку Copy to clipboard (5).

На вкладке History будут показаны пароли, которые были ранее сгенерированы.

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

Электронный адрес (e-mail) – в это поле вводите реальный электронный адрес. На этот адрес к вам придет письмо от сайта, на котором вы проходите регистрацию с подтверждением вашего e-mail. Обычно в таких письмах присылают ссылку, по которой вы подтверждаете свой электронный адрес. Это делается для того, чтобы на сайте регистрировались реальные люди, а не спам-роботы. После этого, чаще всего, вам придет письмо с данными, которые вы использовали при регистрации (логин и пароль). Помимо этого, с помощью электронного адреса вы сможете восстановить пароль, если забудете его. После процедуры восстановления пароля, к вам на ящик придет письмо либо со старым паролем, который вы забыли, либо вам предложат создать новый пароль. Советуем вам завести отдельный электронный ящик, который вы будете указывать при регистрации. Это будет удобно, вы всегда сможете найти письмо с регистрационными данными нужного сайта.

На сегодняшний день популярными почтовыми сервисами являются GMail, Яндекс Почта и Mail.ru. Все они позволят вам завести почтовый ящик абсолютно бесплатно.

Иногда при регистрации на один раз можно использовать анонимный e-mail.

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

1) Всегда создавайте сложные пароли.

2) Нигде не указывайте пароли (в электронном письме, при переписке с другом и т.д.)

Как зарегистрироваться на сайте?

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

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

А как правильно зарегистрироваться на сайте?

Какие при бесплатных регистрациях существуют нюансы?

Регистрируемся на сайтах

Сайты, требующие регистрацию для доступа к своим ресурсам, обычно на главной странице имеют кнопку "Регистрация".

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

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

Кроме того, сейчас в интернете активно внедряются плагины от социальных сетей, которые позволяют проходить регистрацию на сайте, используя свой логин и пароль от этой социальной сети. Плагины регистрации на сайте есть у таких социальных сетей: Фейсбук, Твиттер, ВКонтакте, Одноклассники, Мой Мир (Мэйл.ру). Другие сети также активно работают в этом направлении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отправка email

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

О регистрации на сайтах

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

Пример удачной регистрации на сайте Tumblr.

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

Что такое регистрация?

Регистрация — это способ сообщить сайту данные о себе и в обмен получить доступ к дополнительным возможностям (например, добавление чего-либо в избранное) или ресурсам (к примеру, файлам) на сайте, которые недоступны гостям.
Регистрация неразделима без авторизации. Фактически, регистрация — это способ получить возможность войти на сайт.
Нередко регистрацию делают обязательной для доступа к сайту. Часто это происходит в социальных сетях, где возможности гостей ограничены по определению.
Но так ли нужна регистрация на сайте для большинства проектов?

Зачем нужна регистрация?

• Владельцу сайта регистрация нужна для создания устойчивого сообщества с социальными связями между пользователями. В обмен на это администрация получает возможность взаимодействовать со своими посетителями напрямую, что достаточно трудно сделать с анонимными пользователями 🙂
• Маркетологу, регистрация, безусловно, нужна для получения данных о посетителях и возможности анонсировать им различные новые возможности проекта, а так же рекламировать спонсоров. Ещё это позволяет строить достаточно стройную статистику: кто наши пользователи, чего они хотят? В долгосрочной перспективе это может быть весьма полезным, ведь зная пользователей и их потребности, мы создаём сайт именно для конкретной аудитории, а не для сферических коней в вакууме.
• Разработчику регистрация нужна, ведь она позволяет привязать к аккаунту пользователя немало возможностей на сайте, которые достаточно трудно реализовать для гостей. Также регистрация позволяет распределять права доступа к различным ресурсам и возможностям на сайте, что также облегчает жизнь программистам.
• Большинству посетителей сайта регистрация не очень нужна. В большинстве случаев ему не нужны дополнительные возможности, он довольствуется малым. Нередко люди совсем не понимают её суть: что, вообще, такое, эта загадочная регистрация? Часто это слово ассоциируется с бюрократией и паспортными столами, что отпугивает потенциальных пользователей. Однако, необходимо упомянуть, что социальные сети постепенно просвещают пользователей и позволяют им приобрести первый опыт регистрации. После этого большинство людей гораздо более лояльно относятся к процессу регистрации и понимают, что за ней стоит.

Обычная регистрация

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

Стандартный способ регистрации на сайте StartupPoint.

• Считаю, что в обычной регистрации должен быть минимум полей для заполнения. В идеале — логин, пароль и дубликат пароля, для избежания опечаток.
• Логином может выступать что угодно. Однако в результате долгой работы над этим вопросом я пришёл к выводу, что лучше всего использовать электронную почту для средне и сильно продвинутой аудитории, а также номер телефона для массовых сервисов и проектов. А лучше — дать пользователю выбор. Использовать в качестве логина имя, ник или уникальные ID — не самая удачная идея, которая порождает больше проблем, чем решает.
• Не стоит создавать искусственные рамки при вводе пароля. Если человек хочет ввести «12345», то запрещать ему не стоит, однако, лучше уведомить его о том, что это очень небезопасно, влечет за собой большие возможности для «взлома» аккаунта злоумышленниками и делать так не стоит. Разумный человек это поймет, если ему доходчиво объяснить, а неразумного это не остановит.
• Лучше оставить поле для повторного ввода пароля. Вслепую люди часто опечатываются, а если не скрывать поле пароля, то пользователь не станет регистрироваться на сайте из публичных мест, что тоже является большим ограничением.
• Не думаю, что Captcha — хороший способ отсеивать ботов. Если быть точным, то я не против её применения, однако только после того, как пользователь ввел неправильно свой пароль несколько раз. Это достаточно явный признак того, что ведётся перебор пароля. Идеальным решением для таких случаев считаю показ удобной для человека капчи и ссылки на восстановление пароля с пояснениями на случай, если это действительно живой человек, который запамятовал свой пароль.

Регистрация с помощью сторонних сайтов

Под этим определением я понимаю регистрацию с помощью аккаунта в социальных сетях, через идентификатор OpenID (почти мёртвая технология для масс) и, отдельно, регистрация с аккаунтом больших систем вроде Google, Яндекс и других. Да, иногда это тоже OpenID внутри, но для стороннего человека само определение «OpenID» — филькина грамота.

Регистрация с помощью сторонних сервисов на сайте Кинобаза.

• Самый безболезненный способ регистрации сейчас — именно через аккаунт в социальных сетях и больших проектах вроде Google. Владельцу сайта он позволяет быстро интегрироваться в социальную сеть, а большинству людей не приходится регистрироваться на ещё одном сайте: придумывать пароль, светить свою электронную почту.
• OpenID — почти мёртв как бренд, но процветает как технология. Если планируете дать такую возможность пользователям, не стоит упоминать это слово: оно вводит людей в заблуждение и непонимание. Проще написать «войдите с помощью аккаунта на сайте» и перечень: Google, Яндекс, Одноклассники
• В регистрации через сторонние сайты есть один подводный камень: после выбора сервиса людям выдаётся диалог с просьбой разрешить доступ к своим личным данным. И это именно тот момент, на котором обрывается большинство регистраций через социальные сети. Если люди не доверяют сайту, то с большой долей вероятности они не дадут разрешение. Однако доверие — тема для совсем другой статьи 🙂

Пример диалога с просьбой о доступе к данным на сайте Twitter.

Мягкая регистрация

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

Пример мягкой регистрации на сайте SoundCloud.

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

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

Регистрация во время оформления заказа на сайте интернет-магазина Розетка.

Главное — не давить. Мягкой эта регистрация называется из-за того, что помогает человеку сделать выбор и упрощает ему жизнь, а не навязывается.
Этот способ позволяет вовлечь человека в процесс регистрации так, что он ему понравится, даже если он его заметит. А постепенное вовлечение — сильная штука, гораздо более эффективная, если сравнивать с обычной формой регистрации.

Нужна ли регистрация вообще

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

Если вы ответили «Да» хотя бы на два вопроса, то регистрацию вам применять всё-таки стоит 🙂

Какой способ регистрации использовать

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

Два пути регистрации на сайте Dribbble.

• Сервисы, тесно связанные с деньгами, не стоит интегрировать с другими сайтами и сервисами,- это может поставить под удар безопасность аккаунта. Однако, в таких случаях можно использовать вовлечение в мягкую регистрацию, вместе со стандартным способом.
• Мягкая регистрация — не всегда удачный способ вовлечения, если на проекте нет какого-либо основного действия. Таким действием в интернет-магазине является выбор и заказ товара. Внимательно присмотритесь к своему проекту и выделите такое действие. Можно ли начать его выполнять без аккаунта? Если да — то мягкая регистрация для вас.
• Обычная регистрация почти не работает, по сравнению с другими способами, если проект действительно массовый и направлен на самую широкую аудиторию с невысокой компьютерной грамотностью.

PPS от автора: Надеюсь, вам понравилась статья. Буду рад, если вы укажете на ошибки, чтобы я мог их оперативно исправить. Пишите мне в личку, пожалуйста 🙂