Comments 21
Молодец. Отличная статья. А то я с контактовской авторизацией долго мучался…
Есть в NuGet.
Как же это ласкает мое ухо!
Хочу такой плагин к вордпрессу! Заверните пожалуйста :-)
хочется добавить комментарий, типа «Молодцы!» :)
Как-то много танцев с бубнами получается.
Реально если прочитать спецификацию OpenId 2.0 — все можно сделать очень просто даже своими руками.
А самое грустное (имхо) — что вы не понимаете как работает вся эта кухня, просто пытаетесь подогнать ее под работу библиотеки dotNetOpenAuth.
Более того, я уверен что вы оставили пару лазеек для обхода этой аутентификации, т.к. не установили тот же Callback URL. Этот колбэк должен дернуть сервис если пользователь отказался аутентифицироваться. И вы на это дергание должны удалить хранимую запись об аутентификации. Это кстати нужно и чтобы защититься от Replay атаки на OpenID.
Уверен что частично вас спасает сама библиотека т.к. наверняка делает много проверок по стандарту. Но если вам понадобится схема чуть сложнее, чем «эй либа, получи для юзера какой-нить емейл чтобы я ему поверил», например load-balancing, когда пользователь может прийти от провайдера не на тот сервер, который его отправил, у вас все сломается и вы даже не будете иметь представления — почему сломалось, не говоря уж о том, как это исправить.
PS: При СlaimedId можно сделать discovery шаги по известному адресу и вы получите данные, с которыми надо работать. Claimed от op-endpoint отличается только в том, что в первом случае юзер говорит — «я владею таким-то Id» вашему сервису, а во втором — он это доказывает на самом сервере провайдера…
Реально если прочитать спецификацию OpenId 2.0 — все можно сделать очень просто даже своими руками.
А самое грустное (имхо) — что вы не понимаете как работает вся эта кухня, просто пытаетесь подогнать ее под работу библиотеки dotNetOpenAuth.
Более того, я уверен что вы оставили пару лазеек для обхода этой аутентификации, т.к. не установили тот же Callback URL. Этот колбэк должен дернуть сервис если пользователь отказался аутентифицироваться. И вы на это дергание должны удалить хранимую запись об аутентификации. Это кстати нужно и чтобы защититься от Replay атаки на OpenID.
Уверен что частично вас спасает сама библиотека т.к. наверняка делает много проверок по стандарту. Но если вам понадобится схема чуть сложнее, чем «эй либа, получи для юзера какой-нить емейл чтобы я ему поверил», например load-balancing, когда пользователь может прийти от провайдера не на тот сервер, который его отправил, у вас все сломается и вы даже не будете иметь представления — почему сломалось, не говоря уж о том, как это исправить.
PS: При СlaimedId можно сделать discovery шаги по известному адресу и вы получите данные, с которыми надо работать. Claimed от op-endpoint отличается только в том, что в первом случае юзер говорит — «я владею таким-то Id» вашему сервису, а во втором — он это доказывает на самом сервере провайдера…
Недавно занимался прикручиванием OpenID, и по моему это все в полном хаосе. Большинство провайдеров просит ввести полный опенайде, для логина, что пользователю не особо проще. Гугл отдельный кедр, там логин вводить не надо пользователю на стороннем саййте. Вконтакте вообще пошел своим путем. У меня еще к яндексу одна либа не цеплялась.
И вот не смотря на все эти разночтения, вы еще говорите, что использовать библиотеку это моветон? Это технология же должна была упрощать жизнь, а не усложнять ее. Следовательно и библиотеками для работы с ней должно быть легко пользоваться :(
И вот не смотря на все эти разночтения, вы еще говорите, что использовать библиотеку это моветон? Это технология же должна была упрощать жизнь, а не усложнять ее. Следовательно и библиотеками для работы с ней должно быть легко пользоваться :(
Гугль заявляет что умеет и с id и без. Без пользовательского id — проще схема. С пользовательским id — работает на Stackoverflow.
Далее — если кто-то из провайдеров неправильно реализует описанный стандарт — этим ОП даже пользоваться не стоит, ИМХО. Другое дело — все ленивые и реализуют только те части стандарта которые им нравятся или которые более приоритетны ( например в части Discovery данных). Все ваши сложности скорей всего были в том, что вы не использовали discovery провайдеров — следовательно вам приходилось угадывать а что провайдер умеет и подбирать сэмплы как это прикрутить. Почитайте спеку ( мне пришлось раза три прочитать) — она не такая уж большая, зато вы поймете как должен вести себя тот или иной провайдер на основании тех данных что он о себе открывает в discovery.
B еще — я понимаю что для рекламы многие обещали простую жизнь пользователям. Но вот я не слышал чтобы обещали простую жизнь разработчикам.
Или вы хотели суперсхему для аутентификации чтобы была и простая и доверенная? Такого не бывает — для доверенности схемы необходимы проверки. Дальше будет хуже — например в oauth надо вообще ключиками обмениваться и подписывать запросы, это куда сложнее чем генерить 2-3 get\post запроса в openid. Таковы они, доверенные схемы в недоверенной среде.
PS: к тому же выбранная библиотека — этакий универсальный комбайн — и чтец и жнец и на дуде игрец — конфигурировать можно и как сервер и как клиент и как оба сразу, а еще можно всякие прослойки прикручивать в каждое отверстие. Поэтому важно понимать что именно, как и на каком этапе происходит ( и соответственно — что именно предоставляет библиотека для каждого этапа обработки).
Далее — если кто-то из провайдеров неправильно реализует описанный стандарт — этим ОП даже пользоваться не стоит, ИМХО. Другое дело — все ленивые и реализуют только те части стандарта которые им нравятся или которые более приоритетны ( например в части Discovery данных). Все ваши сложности скорей всего были в том, что вы не использовали discovery провайдеров — следовательно вам приходилось угадывать а что провайдер умеет и подбирать сэмплы как это прикрутить. Почитайте спеку ( мне пришлось раза три прочитать) — она не такая уж большая, зато вы поймете как должен вести себя тот или иной провайдер на основании тех данных что он о себе открывает в discovery.
B еще — я понимаю что для рекламы многие обещали простую жизнь пользователям. Но вот я не слышал чтобы обещали простую жизнь разработчикам.
Или вы хотели суперсхему для аутентификации чтобы была и простая и доверенная? Такого не бывает — для доверенности схемы необходимы проверки. Дальше будет хуже — например в oauth надо вообще ключиками обмениваться и подписывать запросы, это куда сложнее чем генерить 2-3 get\post запроса в openid. Таковы они, доверенные схемы в недоверенной среде.
PS: к тому же выбранная библиотека — этакий универсальный комбайн — и чтец и жнец и на дуде игрец — конфигурировать можно и как сервер и как клиент и как оба сразу, а еще можно всякие прослойки прикручивать в каждое отверстие. Поэтому важно понимать что именно, как и на каком этапе происходит ( и соответственно — что именно предоставляет библиотека для каждого этапа обработки).
Хотел еще про лицензию написать, да оказывается они сменили — теперь BSD
С подсветкой кода было бы лучше.
Как раз нужна была такая штука. Спасибо вам огромное!
> и хочется добавить комментарий, типа «Молодцы!»
Это быстро проходит. Остаются несколько любимых сайтов, а где наследил, где натоптал по одному комменту — уже всех следов-тропинок и не найдёшь и не вспомнишь.
Это быстро проходит. Остаются несколько любимых сайтов, а где наследил, где натоптал по одному комменту — уже всех следов-тропинок и не найдёшь и не вспомнишь.
UFO just landed and posted this here
Пробую в бизнес центре подключиться к wi-fi. Мне предлагают авторизоваться через OAuth (vk, fb, twitter). Какой смысл в авторизации, если они не получают инфорацию о том, кто подключился? Или все-таки получают? Какую еще информацию они смогут выудить из моего аккаунта при авторизации? Почему OAuth, а не OpenID? Там бы я сказал, что я — zelserg без риска передачи пароля или какой другой информации о себе (телефоны, e-mail и пр).
Sign up to leave a comment.
OpenID, OAuth и другие плюшки