Давно хотел создать какой-нибудь видеоролик. Сегодня наконец скачал Pinnacle Studio и всего за 8 часов записал своё первое видео. И глядя на мой блог неудивительно, что этот ролик - про OpenID. Надеюсь, работа не пройдёт даром и материал будет кому-нибудь полезен.
Вот, собственно, сам ролик:
При обсуждении темы о масках в ЖЖ был поднят вопрос об OpenID, достаточно важный в свете разрастающегося вокруг OpenID шума. Что же такое на самом деле OpenID? Что он даёт пользователям и сервисам, а чего не даёт (несмотря на то, что многие думают иначе)?
Популярность OpenID во многом связана с тем, что он, как и всё гениальное, очень прост. Он не требует отдельных центральных серверов, не требует от обеих участвующих сторон никаких дополнительных знаний кроме знания самого протокола. Всё, что нужно для его функционирования уже есть в интернете повсеместно.
OpenID позволяет людям получить уникальный идентификатор, который (если это требуется и если никто ничего не взломает) не может быть использован никем кроме его владельца. Сайтам OpenID предоставляет надёжный способ отличать один идентификатор от другого (ни Cookie, ни IP адрес такой возможности не предоставляют).
Также OpenID позволяет передавать и получать пользовательские данные, что также удобно как пользователю так и сайту.
На этом его возможности, в общем то, заканчиваются.
А теперь немного о заблуждениях, связанных с OpenID:
Почему-то распространено мнение, что пользователю, залогинившемуся по OpenID стоит доверять больше, чем пользователю, просто заполнившему форму “Имя, Емейл, Текст комментария”. Это не так. И это явным образом указывается в спецификации (SRE и AX).
OpenID не отменяет ни одну проверку пользователя, которую он проходит при обычной регистрации. OpenID со стороны сайта - это, грубо говоря, просто строка, введённая в поле “Ваше имя”, ежели такое поле было бы на сайте. Это пользователю он даёт возможность получить уникальный идентификатор (если хотите, имя), который не смогут использовать другие. Для сайта же ничего подобного OpenID не предоставляет. Это пользователь может получить некоторые гарантии своей уникальности, но не сайт. Со стороны сайта основываясь только на OpenID нельзя быть уверенным ни в том, что один пользователь использует только один идентификатор, ни в том, что один идентификатор используется только одним пользователем.
Получить же идентификатор не представляет труда. На сайте OpenID есть большой список OpenID-провайдеров, среди которых есть и анонимные (т.е. не требующие регистрации). Поэтому мысль о том, что пользователь затратил некоторые силы на получения идентификатора и посему не будет хулиганить, не выдерживает критики.
Конечно, можно использовать OpenID для составления белых списков, чёрных списков, уровней доверия и прочего, но в этом плане он ни чем не отличается от e-mail или IP-адреса.
Кратко подводя итог:
OpenID даёт сайту возможность надёжно отличать один идентификатор от другого (т.к. URL уникальны) и стандартным образом получать пользовательские данные
OpenID даёт пользователю возможность получить уникальное имя в сети и передавать сайтам свои данные стандартным образом.
Period.
OpenID - несомненно, полезный механизм как для пользователей, так и для владельцев сетевых ресурсов.
Пользователям он даёт:
Для владельцев сайтов тоже есть преимущества:
Благо, сейчас достаточно хороших библиотек для работы с OpenID и достаточно OpenID-провайдеров (в том числе многие социальные сети), чтобы эта фича была востребована на сайте.
Сейчас я расскажу и покажу, как за пару часов добавить поддержку OpenID к существующему сайту. Я не рассматриваю случаи, когда сайты построены на основе популярных движков (вроде WordPress или Drupal), для которых существуют плагины, делающие за вас всю работу. Речь будет идти о сайте в самом общем случае.
Эту статью я решил написать после подключения OpenID к своему сайту maskas.ru, на котором можно посмотреть рабочую версию того, что я сейчас покажу.
Работать это, как и сам сайт, будет на PHP с использованием библиотеки PHP OpenID Library.
Предполагается, что на сайте уже есть таблица с пользователями, которая используется как основное хранилище данных о них.
Архив со всеми скриптами, которые будут использоваться, можно скачать с меня: здесь.
Итак, приступим.
Для начала скачайте библиотеку и перенесите папочку Auth туда, где php-скрипты смогут найти её при использовании include.
Теперь создадим таблицу связей OpenID-идентификаторов с пользователями.
CREATE TABLE `openid_user_ref` (
`openid` varchar(255) NOT NULL,
`user_id` int(11) NOT NULL,
PRIMARY KEY (`openid`)
)
Нужно добавить куда-нибудь на сайт (скорее всего, туда же, где находится форма логина) форму с одним полем ввода для OpenID-идентификатора, перенаправляющую нас на страницу, на которой будет происходить проверка подлинности идентификатора. Выглядеть это будет примерно так:
<form method="get" action="openid_verify.php">
OpenID: <input name="openid_url" type="text" />
</form>
Для лучшей узнаваемости можно добавить к полю ввода картинку вроде 
такой.
Переписываем файлы из моего примера в корень своего сайта (потом вы сможете их поместить куда нужно, придётся только кое-где поменять пути). Файл openid_verify.php вам трогать, скорее всего, не придётся - он занимается тем, что проверяет правильность введённого OpenID-идентификатора и перенаправляет пользователя на сайт OpenID-провайдера для проверки. В нём вам может понадобиться изменить только список запрашиваемых данных пользователя здесь:
$sreg_request = Auth_OpenID_SRegRequest::build(
// Required
array('nickname'),
// Optional
array('fullname', 'email','gender'));
Файл openid_complete.php уже интереснее. На него пользователь попадает после проверки провайдером и здесь совершаются все необходимые действия по добавлению пользователя в базу или логину. Я написал просты заглушки на нужные функции (создания пользователя, его логина в систему), которые вам нужно будет заменить на что-то более подходящее.
В моём примере логика такая: если OpenID-идентификатор нам неизвестен, мы автоматически создаём нового пользователя с данными, предоставленными OpenID-провайдером. Если идентификатор известен - логиним пользователя.
При создании пользователя используется ник, полученный от OpenID-провайдера. Если ник не получен или полученный ник не подходит (что проверяется функцией check_nickname), то он генерируется из OpenID-идентификатора.
Список данных о пользователе, которые теоретически можно получить от провайдера, достаточно скромен (т.к. используется расширение SRE, описанное в статье обмен пользовательскими данными в OpenID), но все основные данные получить можно.
Для начала вы можете просто распаковать пример в какую-либо папку на сервере и запустить - он работоспособен и сам по себе (особенно если указать правильные параметры для подключения к MySQL в файле openid_common.php). После замените заглушки по созданию пользователя и логину на подходящие для вашего сайта функции и готово - пользователи могут регистрироваться и заходить на ваш сайт при помощи OpenID.
Если вы используете библиотеку под Windows, то вам, скорее всего, нужно установить переменную Auth_OpenID_RAND_SOURCE из файла CryptUtil.php в null.
Не забывайте чистить директорию со временными файлами (путь к ней указывается при создании объекта Auth_OpenID_FileStore). Если ваш сайт достаточно посещаемый, то через время она может начать занимать заметное место на диске.
Я не рассматривал здесь вопрос прикрепления OpenID-идентификаторов к существующим пользователям и объединения OpenID-идентификаторов в одного пользователя. Всё это можно дописать на основе вышеизложенного.
Недавно я писал о том, что блог-сервис Google Blogger начал тестирование комментариев с логином с помощью OpenID.
Тестирование заняло две недели, и вот теперь эта фича доступна на всех блогах.
Чтобы включить возможность владельцам OpenID-аккаунтов комментировать на вашем блоге достаточно в настройке “Кто может комментировать” выбрать “Зарегистрированные пользователи”, что теперь включает в себя и пользователей, залогинившихся под OpenID.
Многие из тех, кто уже слышал слово OpenID, считают его всего лишь парой логин-пароль, которую при некоторых условиях можно использовать на нескольких (а в идеале - почти на всех) сайтах. Но это не совсем так. OpenID позволяет делать другие не менее полезные вещи.
Почему я должен вводить свои данные снова и снова на каждом сайте, где регистрируюсь? Без этого вопроса обходится мало обзорных статей об открытых форматах переносимых данных (одним из которых является и OpenID). И, как и некоторые другие стандарты, OpenID может помочь вам в этом. Не обещаю, что вам не придётся вводить вообще никаких данных о себе, но с большей частю основных данных OpenID сможет справиться.
В первой версии OpenID существует расширение Simple Registration Extension (спецификация). Во второй версии, которая наконец появилась официально 5 декабря, предусмотрен значительно расширенный функционал передачи пользовательских данных, называемый OpenID Attribute Exchange (спецификация). Attribute Exchange (AX) уже поддерживают многие OpenID-провайдеры (OP). Очередь за сайтами и сервисами.
Рассмотрим оба способа подробнее:
Возможности этого расширения достаточно скромные, но оно позволяет передавать 9 полей персональной информации при логине пользователя с помощью OpenID.
Для того, чтобы получить эти данные, сайт или сервис (по официальной терминологии - Relying Party, RP) должен отправить некоторые дополнительные параметры к запросу при перенаправлении пользователя на сайт OpenID-провайдера. RP может указать, что некоторые параметры являются обязательными (например, nickname), а некоторые - опциональными (например, почтовый индекс). При этом проверка введённых данных и их наличия полностью лежит на RP. В спецификации указано, что сайт должен обращаться с данными, полученными от OpenID-провайдера так же, как если бы пользователь ввёл их в ручную и отправил форму.
С помощью Simple Registration Extension можно получить следующие данные о пользователе (если он их ввёл и разрешил отправлять):
Эти поля уже понимают многие OpenID-клиенты и большинство библиотек умеют с ними работать (вряд ли можно считать полноценной библиотекой ту, что не умеет).
Поскольку возможности SRE сильно ограничены, был создан протокол OpenID Attribute Exchange. Принцип его работы похож - при OpenID-запросе посылаются дополнительные параметры с указанием полей, которые желательно получить от OpenID-провайдера.
Attribute Exchange отличается в лучшую сторону следующим:
Если провайдер OpenID не знает каких-то данных пользователя, запрашиваемых сайтом, он может попросить ввести их (с указанием типа данных). Также провайдер может позволить пользователю настраивать политики относительно передаваемых данных (на некоторые сайты передавать всё, на другие - только ник и т.п.). Как частный случай, провайдер OpenID может генерировать одноразовый e-mail для некоторых регистраций.
Кроме OpenID существуют и другие способы получать информацию о пользователе по его URI. Это и representative hCard и связанный со страницей FOAF-файл. У них есть свои преимущества (hCard могут читать и люди, FOAF может хранить большое количество другой полезной информации), и недостатки (требуется дополнительные запросы к страницам и библиотеки для парсинга).
Я думаю, в том, что касается регистрации и получения основных данных пользователя OpenID удобнее и быстрее. А значит у этого механизма большое будущее.
