Публикации с меткой «OpenID»

Взгляд в будущее

    В последнее время всякие социальные сети и вообще сервисы-лидеры интернета по посещаемости и количеству аккаунтов завели очень неплохую, на мой взгляд, привычку — предоставление уникальных OpenID-идентификаторов для пользователей, дабы с их использованием можно было зайти на сторонний сайт. Кроме того, параллельно развивается очень похожая, но все-таки не совсем производная технология OAuth, которая появилась на свет благодаря стараниям создателей небезызвестного Twitter и, цитируя википедию, «позволяет предоставить третьей стороне доступ к защищенным ресурсам пользователя, без необходимости передавать ей (третьей стороне) логин и пароль».
    Лично меня такая тенденция очень радует и, более того, я почти уверен, что за подобной технологией будущее. В частности, в будущем обязательно появятся новые мэшапы для аггрегирования информации с кучи сайтов (в частности, хочется вспомнить очень хороший, но несправедливо забытый сервис Yahoo Pipes, который так и не смог покорить сердца и умы просто потому, что его время тогда еще не пришло. Возможно, все еще впереди), а именно такой «форм-фактор» требует логина на кучу сервисов сразу.

Scipio is a new OpenID consumer for Django. It pretend to become a mainstream Django's OpenID consumer.

Люций Корнелий Сципион по прозвищу Бородатый жил в Древнем Риме порядка трёх сотен лет до нашей эры. Был он не самым безвестным человеком. Сначала военачальником, довольно успешным, выигравшим несколько известных битв. А к концу жизни дослужился до должности консула. Но помимо прочего, был он ещё и цензором.

Дойдя до наших дней, слово “цензор” утратило большую часть своих первоначальных значений, и сейчас означает человека, который не пускает к публикации материалы, подвергающие опасности текущий государственый строй. Однако в Древнем Риме основной работой цензора был, как ни странно, ценз. Под цензом понимался всего навсего учёт граждан республики с их имуществом, общественным положением и родом деятельности. По-современному говоря — перепись населения.

Надо сказать, что тогдашние цензоры к этой части своей работы относились без особого трепета, и точность данных этих переписей была довольно условной. Вроде как сейчас. Но вот этот самый Сципион Бородатый был известен как раз тем, что действительно этим занимался, и провёл довольно точную перепись.

И вот вслед за римлянином Цицероном, именем которого я назвал свой форум, я решил взять имя Сципион (Scipio) для своего следующего интересного проекта. Это OpenID-консумер для Джанго, который умеет регистрировать пользователей (буквально вести перепись) и хранить информацию о их лояльности или нелояльности.

Проект Scipio

Сразу самое важное:

• страница проекта Scipio на Launchpad
• группа django-openid-scipio на Google Groups (язык английский)

В отличие от Cicero, который я делал “в одно лицо” и для себя, Scipio я хочу сделать открытым проектом. Глобальная цель этого проекта — создание хорошего, полнофункционального решения для сайтов на Django, которые хотят принимать у себя OpenID-пользователей. И вообще хочется, чтобы он стал в итоге де-факто OpenID-консумером для Джанго-проектов.

Я уже довольно давно твержу, что основная проблема OpenID, как технологии, в том, что реализовывать её “приёмную” часть довольно трудно, и Scipio — это то, чем я хочу исправить ситуацию.

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

Текущий статус

Сейчас Scipio представляет собой выдранный из Cicero OpenID-консумер, и никаких фич, делающих его очень особенным, в нём пока нет. Однако он уже вполне юзабелен (собственно, форум как раз его сейчас использует). В частности он умеет:

• аутентифицировать пользователя по OpenID (!)
• заводить Django-пользователя с по возможности хорошим username’ом
• вести OpenID-профиль с никнеймом и галочкой доверия (спамер/не спамер)
• работать с whitelist’ами: отдавать список своих проверенных пользователей и читать списки с чужих сайтов
• проверять активность пользователей через настраиваемый антиспам-конвейер

Так что в принципе, его можно уже брать прямо в таком виде.

Тем не менее, у меня туча планов про то, что туда нужно дописать :-). Что именно, и в каком виде там хочется сделать, я в ближайшее время актуализирую на wiki, посвященной проекту.

Философия

OpenID — технология непростая. То есть, она была простой в концепции, когда её придумал Брэд Фицпатрик, но потом она развилась, и оказалось, что она затрагивает много вопросов, связанных с Универсальной Идентификацией, на которые сама конкретного ответа не даёт. Да, собственно, и не должна.

На практике это приводит к тому, что программист, взявший в руки библиотеку OpenID для своего языка программирования, предстаёт перед уймой вещей, которые можно понять неправильно и сделать всем неудобно:

• считать ли OpenID-пользователя “полноценным”
• “кошерно” ли пропускать OpenID-пользователя через регистрацию
• нужно ли давать юзеру иметь несколько OpenID
• принимать ли всех OpenID-провайдеров или только проверенных
• как работать с SRE
• откуда брать дополнительную информацию о пользователе
• какой из URL’ов считать правильным при использовании делегации
• и т.д.

Задача Scipio — выдать готовые решения в ответ на эти вопросы, потому что по ним уже накоплен кое-какой опыт использования.

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

---

Итак — прошу пробовать!

Да, и ещё… Проекту срочно нужна хорошая иконка!

I am going to move from the blogspot to my own blog engine, written in django. The main blocker right now is an OpenID authentication. I am decided to use a Simon Willison's django-openid, but it is still under the heavy development.

Here is my fork of the django-openid with few bugfixes and changes.

The most sugnificant change, on my taste, is a normal URLConf generator which I wrote for consumers. It allows you do not hardcode urls for openid login, registration and so on, but use reverse matching using "reverse" function or template tag {% url %}.

Also, I rewrote all unittest, and now they use a "reverse" function and a normal django.test.Client to talk to the clients. I think, that it is better solution, than to generate a mock WSCGI request and then pass it directly to the consumer's method.

By the way, my URLConf generator can be used to generate URL patterns for any object, which exposes "do_something" methods. For each of these methods, generator creates an URL pattern "^something/" and binds it to the object's method. "do_index" is binded to the "^$" pattern, however.

Second useful change, which I made in the django-openid is a AutoRegistration consumer, which automatically creates auth.User on login by open id. It trying to figure out some information about user requesting optional SREG data from the OpenID provider.

And finally, the dessert! I add an advanced login form, which uses newforms' MultiWidget and allow user do not guess, what does the "OpenID" mean, but just choose one of the popular services, where he has an account, from the select box and input his name on this service. I belive, that this is the most right way from the usability's view point.

I am hope, that Simon Willison will accept these changes to the django-openid's trunk somewhere, but now I am going to synchronize our repositories by hand. Stay tuned and look on my branch on the github.

I am going to move from the blogspot to my own blog engine, written in django. The main blocker right now is an OpenID authentication. I am decided to use a Simon Willison's django-openid, but it is still under the heavy development.

Here is my fork of the django-openid with few bugfixes and changes.

The most sugnificant change, on my taste, is a normal URLConf generator which I wrote for consumers. It allows you do not hardcode urls for openid login, registration and so on, but use reverse matching using "reverse" function or template tag {% url %}.

Also, I rewrote all unittest, and now they use a "reverse" function and a normal django.test.Client to talk to the clients. I think, that it is better solution, than to generate a mock WSCGI request and then pass it directly to the consumer's method.

By the way, my URLConf generator can be used to generate URL patterns for any object, which exposes "do_something" methods. For each of these methods, generator creates an URL pattern "^something/" and binds it to the object's method. "do_index" is binded to the "^$" pattern, however.

Second useful change, which I made in the django-openid is a AutoRegistration consumer, which automatically creates auth.User on login by open id. It trying to figure out some information about user requesting optional SREG data from the OpenID provider.

And finally, the dessert! I add an advanced login form, which uses newforms' MultiWidget and allow user do not guess, what does the "OpenID" mean, but just choose one of the popular services, where he has an account, from the select box and input his name on this service. I belive, that this is the most right way from the usability's view point.

I am hope, that Simon Willison will accept these changes to the django-openid's trunk somewhere, but now I am going to synchronize our repositories by hand. Stay tuned and look on my branch on the github.

Такой маленький пост, чисто похвастаться. :) Вот уже несколько месяцев благополучно работают обе части OpenID в движке - и клиент, и сервер. Ни одного бага (кроме небольшого, связанного с траблами реверс-проксирования и не имеющего отношения к логике работы) с тех пор, как мы закончили встраивать DjangoID (главным образом усилиями Олега) в Byteflow, т.е. примерно с марта. Ура! :)

Такой маленький пост, чисто похвастаться. :) Вот уже несколько месяцев благополучно работают обе части OpenID в движке - и клиент, и сервер. Ни одного бага (кроме небольшого, связанного с траблами реверс-проксирования и не имеющего отношения к логике работы) с тех пор, как мы закончили встраивать DjangoID (главным образом усилиями Олега) в Byteflow, т.е. примерно с марта. Ура! :)

Этот пост будет кратким - благодаря стараниям Олега в Byteflow теперь присутствует сервер OpenID. Клёво. :-)

P.S. А ещё byteflow - второй по тегу django на ohloh.net, после самой джанги. :-)

Этот пост будет кратким - благодаря стараниям Олега в Byteflow теперь присутствует сервер OpenID. Клёво. :-)

P.S. А ещё byteflow - второй по тегу django на ohloh.net, после самой джанги. :-)

Что-то меня прям пробило на код. :-) 4 месяца ничего не трогал, а за последние два дня прям сделал выше всяких норм. :-) В общем, OpenID работает. Причём он привязан к собственной джанговой системе аутентификации.

При логине с новым опенидом предлагается либо создать нового пользователя, либо привязать этот опенид к существующему пользователю (только введя пароль, иначе никак :)). К одному пользователю, что естественно и удобно, может быть привязано несколько OpenID'шных аккаунтов.

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

P.S. Сама поддержка OpenID - это django-openidconsumer Саймона Виллисона с патчем Benoit'а Chesneau (ух, затрудняюсь это на русском написать ;))

P.P.S. Если будут замечены глюки или баги, просьба отписать в комментариях или создать новый тикет в траке.

Что-то меня прям пробило на код. :-) 4 месяца ничего не трогал, а за последние два дня прям сделал выше всяких норм. :-) В общем, OpenID работает. Причём он привязан к собственной джанговой системе аутентификации.

При логине с новым опенидом предлагается либо создать нового пользователя, либо привязать этот опенид к существующему пользователю (только введя пароль, иначе никак :)). К одному пользователю, что естественно и удобно, может быть привязано несколько OpenID'шных аккаунтов.

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

P.S. Сама поддержка OpenID - это django-openidconsumer Саймона Виллисона с патчем Benoit'а Chesneau (ух, затрудняюсь это на русском написать ;))

P.P.S. Если будут замечены глюки или баги, просьба отписать в комментариях или создать новый тикет в траке.