Идеальная регистрация на сайте

OAuth/OpenIDУже давно ничего сюда не писал — особо не было повода. Ведроид вроде бы доведён до ума, Линукс [почти] тоже, да и ничего интересного я с ним не делаю, о чём стоило бы упомянуть. Какие-то интересные веб-сервисы последнее время не попадались на глаза, а новые девайсы не попадались в руки. Поэтому столько времени прошло со времени последнего поста. Но недавно замутил на сайте регистрацию/авторизацию через OAuth (через социальные сети, проще говоря) и OpenID. Что это такое я пояснять не буду, а как всегда пошлю интересующихся в Википедию :-) За время интеграции новых плюшек в сайт появились некоторые мысли о том, какой должна быть идеальная регистрация и авторизация пользователя на веб-сайте. Чем и захотелось поделиться тут. Естественно, всё ниженаписанное ни в коем случае не является 100%-й истиной, а лишь моё мнение с точки зрения даже не разработчика, а простого посетителя некого веб-ресурса. То есть то, какой я хочу видеть регистрацию везде. Но к сожалению, почему-то сайтов с действительно грамотной и удобной регистрацией очень мало — мне буквально попалась всего пара штук, где я подумал, что всё идеально. И что сделал бы так сам. Надеюсь данный пост поможет хоть одному веб-мастеру сделать интернет (а конкретно свой сайт) чуть лучше. Ну и хватит воды, а то её что-то получилось много.

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

При использовании только OAuth тут меньше проблем, а вот при OpenID это казалось бы невозможно, ведь пользователь должен ввести свой OpenID-идентификатор (URL). Но на самом деле, если OpenID-провайдер предоставляет OpenID версии 2.0, то становится возможным использовать общий для всех идентификатор. Некоторые провайдеры, которые имеют такой адрес:
  • Яндекс — http://www.yandex.ru/
  • Google — https://www.google.com/accounts/o8/id
  • Yahoo — http://me.yahoo.com/
  • AOL — http://openid.aol.com/
  • Steam — http://steamcommunity.com/openid
  • возможно есть другие, список будет пополняться.
Эти URL'ы и надо передавать OpenID серверу, как будто пользователь ввел их сам в форме регистрации/логина. Естественно сервер вернёт уже уникальный идентификатор аккаунта, который и надо сохранить в базу.
Небольшое пояснение про Yahoo

Оказалось, Yahoo возващает идентификатор вида https://me.yahoo.com/username#XXXXXX, при чём символы после решётки разные при каждом запросе. Следовательно, перед записью в базу URL надо от них очистить. Зачем так сделано мне лично непонятно.

Конечно же только использование "общего" OpenID-идентификатора не является достаточным условием для "регистрации в один клик". Самое главное: если все обязательные поля профиля пользователя для регистрации заполнены (то есть данные получены через OpenID или OAuth), и при этом их значения уникальны, то форму регистрации вообще не стоит показывать! После возвращения со страницы провайдера достаточно только написать, что регистрация завершена (ну и отправить активационное письмо на email). Если же не всё прошло как надо, например ник, который вернул сервер, уже занят на сайте, то тут уже надо показать форму регистрации и написать в ней ошибку. И вот тут есть 2 варианта: показать всю форму с уже заполненными полями профиля, или показать только те поля, которые надо исправить. Мне больше нравится первый — так пользователь сразу видит, какая инфа о нём известна сайту.

Заполнение как можно большего количества полей профиля

...чтобы пользователь меньше вводил сам. Включая опциональную информацию, типа города, сайта, поля "обо мне", и т.п. При чём через некоторые OpenID-идентификаторы можно получить чуть больше данных, чем OpenID способен вернуть. Например:
  • если использовался OpenID вида http://openid.xmpp.za.net/user@jabber-server.com, то можно заполнить еще и поле с JID'ом;
  • OpenID-адрес от Google может быть и таким: http://profiles.google.com/XXXXXXXXXXXXXXXXXXXXX, соответственно, содержит Google+ ID пользователя.

Получение лишних данные о пользователе

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

Пароль — опционально

Очень часто встречающейся недостаток — это когда после успешного подсоединения OpenID или соцсети предлагается пройти "дорегистрацию" и ввести пароль для доступа на сайт. Зачем, если ради избавления от паролей и упрощения регистрации всё и делается? Хотя, если по какой-то причине форма регистрации показывается, то можно вывести в ней и поле для пароля. Но сам его ввод должен быть уже опциональным.

Нормальное подключение OpenID/соцсетей к существующему аккаунту

Ошибка, с которой сам столкнулся вчера на Spring.me: после попытки входа через Twitter создаётся новый аккаунт, хотя уже был аккаунт с тем же email'ом. Если в настройках сайта нет возможности подключить соцсеть для входа через нее, то попытка такого входа (или по OpenID), если email совпал с имеющимся в базе, должна приводить к объединению существующего "обычного" акка с паролем с новым, что и будет подключением соцсети (или добавлением OpenID-идентификатора) к аккаунту.

OpenID или OAuth

Если один и тот же провайдер предоставляет возможность входа через OpenID и через OAuth, и пользователь уже зарегистрировался одним из способов, то в существующий аккаунт должен быть добавлен OpenID-идентификатор или подключена соцсеть по OAuth. Например, если используется OpenID вида http://profiles.google.com/XXXXXXXXXXXXXXXXXXXXX и при этом в базе уже есть пользователь Google с ID XXXXXXXXXXXXXXXXXXXXX. Для других сетей аналогично, при условии что из OpenID можно извлечь ID пользователя в том же виде, в котором он хранится в базе для OAuth. Для Google это скоро перестанет быть актуальным, т.к. поддержка OpenID, к сожалению, скоро будет прекращена.
Чему могут последовать и другие сервисы, являющиеся также OpenID-провайдерами

Как вышло с Jabber'ом. Яндекс, Mail.Ru, Yahoo, etc. Все вполне могут начать выключать свои OpenID-сервера, только потому что так сделал Google. :-(


Добавление ссылок на профили только через OAuth

Если в профиль пользователя на сайте предполагается добавление ссылок на профили в социальных сетях, то обычные пустые поля для этого должны ОТСУТСТВОВАТЬ. Ссылки на профили нужно добавлять только полученные от OAuth-сервера, чтобы пользователь не мог ввести произвольную.

Напоминане о том, каким способом был произведен вход

Так как на сайтах почти всегда доступно несколько способов входа, пользователь должен помнить, через какую сеть зашел в прошлый раз. Поэтому в форме логина полезно писать что-то типа "Последний раз вы заходили через..." Очень важно, чтобы способ входа (пароль/OpenID/соцсеть) запомнился обязательно после успешного входа, а не при попытке его совершить, т.к. на странице провайдера вход может быть отменён. А сохранять значение можно в cookies или LocalStorage.

Лучше не использовать сторонние сервисы

Их конечно бывает проще настроить и интегровать на собственный сайт, но зачем зависеть от других. Loginza однажды просто забыла продлить домен, из-за чего на сайты, которые её используют, какое-то время нельзя было войти.
На этом всё. Надеюсь, кому-нибудь будет полезным. А источником вдохновения для поста послужила в основном вот эта статья. Там же есть интересная идея интерфейса формы логина, когда само слово "OpenID" скрыто подальше (и даже значок OpenID), вместо этого предлагается "Войти как пользователь %NETWORK%" и только поле для ввода логина.

Комментарии

  1. MGM Resorts Names Former Chairman of - JtmHub
    MGM Resorts has named the former 구리 출장안마 Chairman of 천안 출장샵 the 충청북도 출장샵 Board 제주도 출장안마 of Directors of MGM Resorts International as its Vice Chairman of the 포천 출장마사지 Board of Directors of the

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Как восстановить подключение к сетевым дискам в Windows

Как отключить MTP в Android