Логотип StingRay

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

Реализация OpenId-идентификации пользователей через Loginza

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

Вопрос-проблема № 1. Должно ли введение регистрации посетителей на некоем сайте приводить к запрету анонимного добавления сообщений/комментариев (без регистрации)?
Ответ-решение № 1. Нет, не должно – отсутствие требования обязательной регистрации и возможность добавления без неё сообщений/комментариев на сайт является удобным для его посетителей. Регистрация должна давать какие-то иные преимущества.

С момента того ответа прошло ни много, ни мало, 3 года и 8+ месяцев, прежде чем я сообщил о завершении реализации регистрации посетителей на сайте по протоколу OpenId и через службу Loginza. Эта статья о том, как я шёл по этому длинному пути.

1. Уникальность имён пользователей.
2. Преимущества идентифицированных пользователей.
3. Доверительная сетевая идентификация.
4. Децентрализованная идентификация OpenId.
5. Многовариантная идентификация Loginza.
 5.1. Разные наборы возвращаемых полей.
 5.2. Алгоритм формирования отображаемого имени.
 5.3. Ссылка с публично отображаемого имени.
 5.4. Локальный выход из системы (с сайта).
6. Фактическая востребованность идентификации.

Уникальность имён пользователей

В этом же первом ответе я попытался сформулировать те преимущества, которыми должен будет обладать зарегистрированный посетитель. В частности, я упомянул форум SQL.ru, на котором также разрешены анонимные сообщения, но при этом незарегистрированные пользователи не могут в качестве своих имён использовать имена зарегистрированных пользователей (на самом деле, тут у зарегистрированных пользователей слабое преимущество – только из-за него я бы не стал регистрироваться). Автор идеи меня в этом поддержал, и с тех пор это было единственным явно обозначенным преимуществом зарегистрированных посетителей сайта.

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

Вопрос-проблема № 2. Надо ли запрещать незарегистрированным посетителям (пользователям) использовать при добавлении сообщений/комментариев имена, совпадающие с именами зарегистрированных пользователей?
Ответ-решение № 2. Нет, не надо – это вызывает у незарегистрированных посетителей психологический дискомфорт, нежелание добавлять сообщения/комментарии и вообще отторжение данного сайта.

И несколько технических проблем:

Вопрос-проблема № 3. Если пользователь был зарегистрирован на сайте как “Alexa”, то мы будем запрещать другим, незарегистрированным пользователям использовать это имя, а если потом вдруг зарегистрированный пользователь изменит имя в своём профиле на «Алексей», – что тогда, запрещать все ранее добавленные сообщения/комментарии некоего другого, незарегистрированного пользователя «Алексей»?
Ответ-решение № 3. Нет, не запрещать – запрет/удаление ранее добавленных сообщений/комментариев любых пользователей (как незарегистрированных, так и зарегистрированных) вызывает у пользователей нежелание добавлять новые сообщения/комментарии и вообще психологическое отторжение данного сайта. Проще отказаться от отслеживания уникальности имён пользователей.

Вопрос-проблема № 4. Если пользователь стал регистрироваться на сайте как “Alexa”, но обнаружилась более ранняя регистрация пользователя с таким же именем – что делать в такой ситуации, запрещать ему регистрироваться (под повторяющимся именем)?
Ответ-решение № 4. Нет, не запрещать – запрет регистрации вообще или под дублирующимся именем вызывает у пытающихся зарегистрироваться посетителей (пользователей) психологический дискомфорт, нежелание регистрироваться и вообще отторжение данного сайта. Проще отказаться от отслеживания уникальности имён пользователей.

В результате было решено отказаться от отслеживания уникальности имён пользователей. Но пришлось вернуться к поиску преимуществ зарегистрированных пользователей.

Преимущества идентифицированных пользователей

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

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

  1. Возможность получать по электронной почте уведомления о новых ответах на сообщения пользователя и новых комментариях к интересующей странице, если у зарегистрированного пользователя указан электронный адрес.
  2. Возможность редактирования собственных сообщений/комментариев, на которые пока не дан(ы) ответ(ы), прежде всего как способ исправления собственных опечаток (хотя рекомендуется избегать их, пользуясь предпросмотром Предпросмотр).
  3. Увеличенное время сеанса (60 минут – втрое больше, чем у анонимных посетителей), позволяющее реже сталкиваться с истечением срока идентификации и времени жизни картинки «Результат операции» при написании длинных сообщений/комментариев.
  4. Отсутствие необходимости каждый раз вписывать своё имя в соответствующее поле при добавлении сообщений/комментариев – поле будет автоматически заполняться именем зарегистрированного пользователя.
  5. Сообщения/комментарии добавляются от своего уникального имени, точнее, от возможно неуникального имени, но со ссылкой на уникальный внешний профиль (страницу в соцсети, блог и т. п.).
  6. Сокрытие IP-адресов, которые отображаются рядом с каждым именем автора сообщения/комментария.

Доверительная сетевая идентификация

Пытаясь минимизировать свои потенциальные трудозатраты на реализацию регистрации посетителей на своём сайте (читай – найти лёгкий путь), а заодно использовать современный уровень веб-технологий, я как-то случайно наткнулся на информацию об открытом стандарте OpenId, а также о возможности использовать сугубо Microsoft’овский LiveId для идентификации на стороннем сайте. Общего названия у них тогда не было, да и сейчас я не встречал, поэтому условимся называть эту технологию идентификации доверительной сетевой идентификацией – это вполне отражает их суть («мой сайт доверяет сайту-провайдеру идентификацию пользователя, а тот доверяет моему сайту, как запрашивающему идентификацию»).

К сожалению, OpenId и LiveId не отличались между собой по самому главному для меня критерию – наличию готовых и открытых ASP-библиотек для их использования на моём сайте. LiveId SDK изначально больше ориентировано на ASP.NET-разработку, у OpenId библиотек побольше, но среди них всё равно не было нужной мне ASP-библиотеки (да, да, я всё ещё пишу на старом добром ASP, а не на современном и ультрамодном ASP.NET). 🙁

Поэтому основное различие между OpenId и LiveId заключалось в том, что первый был именно открытым стандартом и поэтому технологией децентрализованной сетевой идентификации, а второй закрытой службой идентификации Microsoft (хоть и с открытым интерфейсом идентификации) – а кто знает, что однажды захочет делать с пользовательскими данными эта мегакорпорация-монополист?.. Поэтому OpenId победил своей «демократией». 😊 И когда чуть позднее, 27.10.2008, LiveId также стал работать и как OpenId-провайдер, я понял, что сделал правильный выбор более общей технологии – OpenId.

OpenId

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

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

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

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

Вопрос-проблема № 5. Нужно ли на моём сайте иметь ещё и какую-то собственную таблицу (базу данных) пользователей? Если да, то что в ней будет храниться?
Ответ-решение № 5. Его на тот момент однозначного не было. Было лишь предположение, что в том-то и преимущество доверительной сетевой идентификации вообще и OpenId в частности, что трудозатраты на реализацию и сложность архитектуры минимальны, в частности, не надо хранить у себя никакой информации о пользователях. Единственное, что пришлось бы хранить, – это признак идентифицированного пользователя, но для этого вполне годилась сеансовая переменная.

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

Вопрос-проблема № 7. Если меняется имя (псевдоним) пользователя, будь то во внешнем профиле или локально на моём сайте, нужно ли все его ранние сообщения и комментарии обновлять и отображать с новым псевдонимом?
Ответ-решение № 7. Если обновлять, то возможна такая проблема: пользователь участвовал в некоем обсуждении под именем «Ваня», и в тексте обсуждения к нему так и обращались, но вдруг он стал «Петей» – и что тогда, все обращения к нему будут выглядеть странно? А если не обновлять, то получится, что один и тот же пользователь может быть автором сообщений и комментариев под разными именами…

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

Loginza

Многовариантная идентификация Loginza

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

В любом случае, для пользователей моего сайта это было бы удобно, иметь сразу столько вариантов идентификации. Но самое главное то, что Loginza обладает максимально простым API и может быть легко внедрена на любом сайте, существенно снижая трудозатраты разработчика на реализацию идентификации посетителей вообще и по протоколу OpenId в частности. Первое впечатление: вот оно, то, что сдвинет с мёртвой точки реализацию идентификации посетителей у меня на сайте!..

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

  • не очень широко известная и используемая служба идентификации (о Loginza я тогда слышал впервые и никогда ранее не встречал её использование на сайтах);
  • отсутствие международного признания (примерно в то же время тот же «директор по инновациям» предложил мне внедрить AddThis, и его статистика внедрения впечатляла: 9 млн доменов и 1 млрд пользователей);
  • в том числе потому, что на тот момент Loginza была сугубо русскоязычной (что было существенным ограничением для моего двуязычного сайта);
  • наконец, будучи бесплатной, Loginza вызывала разумный вопрос о возможной платности в будущем (что, опять же, было существенным ограничением для моего некоммерческого сайта).

И вот как эти опасения были развеяны:

  • ничего аналогичного по функциональности, простоте внедрения и бесплатности я не нашёл тогда ни в Рунете, ни во всём Интернете;
  • международное признание мне заменил короткий комментарий моего друга-разработчика, уехавшего работать в США: «судя по описанию, Loginza – это круто, этим сто́ит заняться»; он же рассказал мне и о западном аналоге – Stack Overflow, который входит в группу сайтов Stack Exchange с единым механизмом идентификации, но соответствующий API пока не позволяет его использовать;
  • по поводу английского языка я сам связался с разработчиками Loginza, перевёл для них все элементы интерфейса на английский язык, и совместными усилиями мы в кратчайшие сроки получили возможность переключать языки (английский был вторым, но сейчас их поддерживается уже больше);
  • про (бес)платность Loginza вопрос на её форуме задал кто-то до меня, и ответ службы поддержки: «Платные функции будут, но только как дополнение по желанию к текущему функционалу», – меня вполне успокоил (вместе с «директором по инновациям» 😊).

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

В процессе предварительного знакомства с последовательностью внедрения был получен окончательный ответ на вопрос, мучавший меня ранее, ещё применительно к OpenId (к Loginza он тоже применим):

Вопрос-проблема № 5. Нужно ли на моём сайте иметь ещё и какую-то собственную таблицу (базу данных) пользователей? Если да, то что в ней будет храниться?
Ответ-решение № 5. Да, нужно. В ней, как минимум, должно храниться значение OpenId-профиля идентифицированного пользователя (identity), а также другие необходимые данные профиля, которые после завершения процесса идентификации будут недоступны.

А тот самый пример со Stack Overflow и пояснения моего друга, регулярно им пользующегося, помогли окончательно ответить на ещё два вопроса:

Вопрос-проблема № 6. Нужно ли предоставлять пользователю возможность изменять своё имя (псевдоним) специально в контексте моего сайта, или всегда брать это значение из OpenId-профиля?
Ответ-решение № 6. Да, “Stack Overflow” позволяет это делать, это удобно. (Вот и ещё одна причина, по которой на сайте нужна локальная таблица/база данных пользователей… Однако на практике я снова долго тянул с реализацией этого пожелания – оно было реализовано почти через год после основного внедрения Loginza.)

Вопрос-проблема № 7. Если меняется имя (псевдоним) пользователя, будь то во внешнем профиле или локально на моём сайте, нужно ли все его ранние сообщения и комментарии обновлять и отображать с новым псевдонимом?
Ответ-решение № 7. Да, “Stack Overflow” поступает именно так. Видимо, просто игнорируя редкие «клинические» случаи полной смены пользователем своего псевдонима.

Да, и “Stack Overflow” совершенно спокойно относится к неуникальности имён пользователей. Хотя ответ на этот вопрос я нашёл и без него.

Разные наборы возвращаемых полей

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

Провайдеры: Facebook Google LiveJournal Mail.ru Rambler Steam Twitter WebMoney Yahoo В контакте Яндекс
Всего попыток: 1 3 2 3 1 1 2 1 2 3 3
успешных: 1 2 2 2 1 1 2 1 2 2 3
Поддержка полей
Provider да да да да да да да да да да да
Identities да
Identity да да да да да да да да да да да
UId да да да да да
Nickname да да да да
Full_Name да да да да
First_Name да да да да
Last_Name да да да да
Email да да да да
Web (Default) да да
Address (Home Country) да да
Biography да
DoB да да да да
Gender да да да
Language да да да
Photo да да да да да

Таким образом, на тот момент из числа поддерживаемых Loginz'ой провайдеров идентификации непроверенными на практике оставались лишь сама Loginza, а также LJ.Rossia.org, MyOpenId, Yahoo, Blogger, Diary.ru, FlickR, WordPress, VeriSign, AOL и Last.fm.

Тем не менее, уже можно было сделать вывод о том, что минимальным набором получаемых полей является Identity (ссылка на внешний профиль идентифицированного пользователя) и Provider (ссылка на провайдера идентификации). При этом из них только Identity могло иметь хоть какое-то значение при формировании отображаемого имени (псевдонима) идентифицированного пользователя, если никаких иных полей получено не было. Настоящий же псевдоним (nickname) встречается в получаемых данных даже реже, чем полное имя (name в виде Full_Name или First_Name + Last_Name).

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

Алгоритм формирования отображаемого имени

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

  1. Если от провайдера получено поле Nickname (псевдоним), то используем его значение.
  2. Если нет, но получено поле Full_Name (полное имя), то используем его значение.
  3. Если и его нет, но получены поля First_Name (имя) и/или Last_Name (фамилия), то используем их значение, соединяемые по формуле “First_Name Last_Name”.
  4. Наконец, если и оба эти поля отсутствуют (их значения пусты), то используем имя пользователя, извлекаемое из значения поля Identity (благо это поле нам возвращается всегда).

То, что в Identity (по сути, в Интернет-адресе) на последнем шаге будет считаться именем пользователя, зависит от провайдера идентификации. В приводимой ниже таблице, иллюстрирующей работу алгоритма, это можно видеть на примере LiveJournal, Rambler и «Яндекса».

Провайдеры \ Поля Nickname Full_Name First_Name Last_Name Identity Имя
Facebook Full Name First Last http://www.facebook.com/profile.php?id=# Full Name
Google First Last https://www.google.com/accounts/o8/id?id=userid First Last
LiveJournal http://user.livejournal.com/ user
Mail.ru Nickname First Last http://my.mail.ru/mail/user/ Nickname
Rambler https://id.rambler.ru/users/user/ user
Steam http://steamcommunity.com/openid/id/# #
Twitter Nickname Full Name http://twitter.com/user/ Nickname
WebMoney Nickname Full Name https://#.wmkeeper.com/# Nickname
Yahoo Full Name https://me.yahoo.com/ Full Name
В контакте Nickname First Last http://vkontakte.ru/userid Nickname
Яндекс http://user.ya.ru/ user
http://openid.yandex.ru/user/

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

Ссылка с публично отображаемого имени

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

  • на его внешний профиль (всегда получаемое значение поля Identity) или
  • на его локальный профиль на моём сайте.

За первый вариант «голосовало» то преимущество зарегистрированных и идентифицированных пользователей, которое автор идеи назвал первым, а я расположил 5-м по значимости – возможность естественным образом давать ссылки на свои внешние профили (блоги и т. п.) со своего имени, то есть возможность авторам сообщений и комментариев на моём сайте «рекламировать» свои ресурсы (хотя они и раньше могли это делать, пользуясь инструментом добавления ссылок Гиперссылка и… моей благосклонностью 😊).

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

Но была выявлена вот какая особенность: ссылки на идентификаторы «Яндекса», Mail.ru, LiveJournal, Twitter, «В контакте», Rambler, WebMoney и Facebook имеют для живого пользователя визуальный смысл, а вот ссылки на идентификаторы Google и Steam указывают на какие-то странные XML-файлы, которые живому пользователю неинтересны и непонятны. Для Google-профилей мне удалось впоследствии найти решение и научиться самостоятельно формировать ссылки на их «человеческие» версии, а вот Steam-профили так и остались странными.

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

Локальный выход из системы (с сайта)

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

Это вообще известная особенность доверительной идентификации, если не один из принципов её построения. В своё время и на форуме Loginz'ы писа́ли, что «мы не имеем возможности сбрасывать авторизацию у провайдеров». Я тогда предложил разработчикам Loginz'ы сделать хотя бы минимум: предоставить пользователю ссылку на сайт провайдера, по которой бы он смог выйти у провайдера. На что мне было отвечено, что они «уже придумали, как сделать реальный сброс авторизации на стороне провайдера, будет реализовываться». Если честно, до сих пор не знаю, было ли это реализовано (и вообще как это возможно)…

Фактическая востребованность идентификации

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

Тем не менее, я ничуть не жалею о том, что прошёл этот длинный и интересный путь реализации. Это, прежде всего, новый и полезный опыт для меня, как аналитика и веб-разработчика. Я также рад, что немного поучаствовал в развитии такой удобной и перспективной службы идентификации, как Loginza (помог сделать её «говорящей по-английски»). А посему хочу сказать большое спасибо моему «директору по инновациям» за идею, настойчивость в напоминании мне о ней, участие в обсуждениях (многие из которых сформировали замысел и текст данной статьи), тестирование и периодическое использование в обычной практике, а также спасибо всем моим друзьям и знакомым, которые так или иначе тоже поучаствовали в обсуждении и/или тестировании.

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

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