Pull to refresh

Главное – хвост! или Отказ от регистрации 2

Website development
Sandbox
Заметка «Отказ от регистрации» взбудоражила мой ум и я часа 2 не мог уснуть (или это была чашка кофе на ночь?..)

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

Решение пришло как раз перед сном, а реализацию сделал сегодня утром. Остался доволен.

Но, обо всём по порядку.



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

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

Формализация идеи


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

Если вдруг пользователю понадобилось где-то на сайте ввести емэйл, то: Ура! – теперь этот пользователь не потеряется. Мы можем позволить ему идентифицировать себя, предложив ввести свой емэйл, в любом браузере и с любого компьютера. Но до авторизации ему не будет доступна история его взаимодействия с нашим сайтом.

А вот, когда пользователь захотел себя авторизовать, то мы высылаем на его емэйл пароль.
Теперь у нас есть зарегистрированный по всем правилам пользователь, причём лояльность этого пользователя ИМХО значительно выше, чем у пользователя, зарегистрированного по «стандартной» схеме.

Реализация идеи


Предлагаю свою версию.

У меня в движке уже есть модуль, собирающий статистику посещений. Сейчас он сохраняет в одну таблицу идентификатор сессии, идентификатор пользователя (по-умолчанию это идентификатор гостя) и всю информацию по запросу. Убираем из таблицы статистики идентификатор пользователя и создаём новую таблицу с двумя полями:
  • Идентификатор сессии;
  • Идентификатор пользователя.

В эту таблицу будем заносить информацию, если:
  • Создаём нового пользователя;
  • Обновляем все строки с текущим безымянным пользователем после идентификации или авторизации текущего пользователя.

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

Привязать в будущем к этой схеме OpenID проблем не составит.

Для реализации механизма сохранения недозаполненных форм создаём такую таблицу:
  • Идентификатор сессии;
  • Идентификатор вида формы;
  • Последний сериализованный пост запрос, связанный с формой.

Думаю ещё сделать подстановку наиболее часто вводимых значений, но это позже.

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

Заключение


Итак, вопрос регистрации для меня больше не проблема. Надеюсь, моё решение пригодится и в ваших проектах.

P.S. Прекрасный мультик про грифа, страуса и ящерицу можно посмотреть здесь.

UPD:
Стандартная «явная» регистрация тоже реализована. Смена пароля и его восстановление есть.

UPD2:
Сферой применения предложенного механизма вижу любой ресурс в независимости от его сложности и масштабности.

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

  2. Важно, что это делает человек (комментарий на обычном сайте и другое такое же простое действие).
    • Защита — обычная капча.
    • Действие доступно любому идентифицированному пользователю, т.е. в нашем случае любому зашедшему на сайт, даже роботу, если он справится с капчей.

  3. Важно, что это делает человек и что он берёт на себя ответственность за это действие (заказ, пост, комментарий на каком-нибудь серьёзном ресурсе).
    • Защита — подтверждение по емэйл.
    • Доступно идентифицированному пользователю без подтверждённого емэйла (понятно, что он может сделать это только один раз) и любому авторизованному пользователю.

С авторизованными пользователями всё понятно. Это стандартная ситуация.

Много разговоров про идентифицированных, но не авторизованных пользователей.

Пока пользователь ни разу не ввёл на сайте свой емэйл, он считается только идентифицированным и может делать любые действия категории 1 и 2 сколько угодно раз. Также ему доступно любое действие из категории 3, но ТОЛЬКО один раз. После успешного выполнения этого действия такой пользователь становится полностью зарегистрированным (признак — наличие подтверждённого емэйла в его профиле), и в следующий раз без авторизации он не сможет выполнять действия категории 3. Теперь пользователь должен сам следить, чтобы его аккаунт не попал в чужие руки (например, мамы). Естественно пользователь уведомляется об этом в письме. Естественно у него появляется кнопка «Выйти».

UPD3:
Проблемная ситуация и её решение

Я идентифицированный пользователь без подтверждённого емэйла или телефона совершил на сайте действие категории 2. В течение жизни моей сессии ещё 100500 пользователей совершили на сайте действие(-ия) категории 2.

Из топика следует, что сайт будет думать, что один пользователь, а именно я совершил все эти 100501 действий категории 2.

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

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

За подробное рассмотрение этого случая отдельное спасибо Nail13.
Tags:регистрацияавторизация
Hubs: Website development
Total votes 82: ↑63 and ↓19 +44
Views1.3K
Sales Development Representative/ Business development manager
from 80,000 to 120,000 ₽RoonyxRemote job
Frontend Development Lead
to 550,000 ₽NUTSonМоскваRemote job
Fullstack разработчик Drupal 8
from 80,000 to 150,000 ₽Caterme.ruRemote job
С# developer
to 220,000 ₽Benchmark ExecutiveСанкт-ПетербургRemote job

Top of the last 24 hours