Логотип StingRay

Социальные сети
FacebookInstagramRSSTwitterYouTubeВ контактеОдноклассники
FacebookInstagramRSSTwitterYouTubeВ контактеОдноклассники
Силуэт человека

Децентрализованная идентификация OpenId

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

OpenId

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

  1. Пользователь моего сайта вводит свой OpenId-идентификатор.
  2. Мой сайт перенаправляет пользователя на сайт соответствующего OpenId-провайдера.
  3. На сайте «родного» OpenId-провайдера пользователь проходит привычную ему аутентификацию и выражает доверие моему сайту (разрешает своему OpenId-провайдеру предоставить информацию профиля моему сайту).
  4. OpenId-провайдер перенаправляет пользователя обратно на мой сайт с указанием на успешную идентификацию пользователя и данными его профиля (за исключением пароля, конечно).
  5. Мой сайт признаёт пользователя идентифицированными и у себя (это же доверительная сетевая идентификация) и выдаёт ему положенные преимущества.

Но с точки зрения технической реализации всё выглядело пугающе непросто. В том числе возникали вот такие вопросы:

  • Нужно ли на моём сайте иметь ещё и какую-то собственную таблицу (базу данных) пользователей? Если да, то что в ней будет храниться? Было предположение, что в том-то и преимущество доверительной сетевой идентификации вообще и OpenId в частности, что трудозатраты на реализацию и сложность архитектуры минимальны, в частности, не надо хранить у себя никакой информации о пользователях. Единственное, что пришлось бы хранить, – это признак идентифицированного пользователя, но для этого вполне годилась сеансовая переменная.
  • Нужно ли предоставлять пользователю возможность изменять своё имя (псевдоним) специально в контексте моего сайта, или всегда брать это значение из OpenId-профиля? Изначально мне казалось, что нет, не нужно, иначе придётся отвечать на предыдущий вопрос положительно (заводить на моём сайте таблицу пользователей, чтобы хранить там изменённые псевдонимы). Я даже умудрялся оправдывать это перед своими пользователями самым нелепым (как сейчас вижу) образом: «это минимизирует конфликты имён и вообще безопаснее». Но позднее всё переменилось…
  • Если меняется имя (псевдоним) пользователя, будь то во внешнем профиле или локально на моём сайте, нужно ли все его ранние сообщения и комментарии обновлять и отображать с новым псевдонимом? Если обновлять, то возможна такая проблема: пользователь участвовал в некоем обсуждении под именем «Ваня», и в тексте обсуждения к нему так и обращались, но вдруг он стал «Петей» – и что тогда, все обращения к нему будут выглядеть странно? А если не обновлять, то получится, что один и тот же пользователь может быть автором сообщений и комментариев под разными именами…

Всё это затягивало процесс реализации, точнее, заставляло меня оправдывать подсознательное откладывание начала реализации… До тех пор, пока я не познакомился с Loginza.

Добавьте свой комментарий или войдите, чтобы подписаться/отписаться.
OpenId
Предпросмотр
Улыбка Подмигивание Дразнит Оскал Смех Огорчение Сильное огорчение Шок Сумасшествие Равнодушие Молчание Крутизна Злость Бешенство Смущение Сожаление Влюблённость Ангел Демон Задумчивость Рука-лицо Не могу смотреть Жирный Курсив Подчёркивание Зачёркивание Размер шрифта Гиперссылка Цитата
Загрузка…