Нарисовалась тут проблема, что Cicero не принимает OpenID от Yahoo. А я как раз "удачно" заболел, поэтому появилось время подробно поразбираться в проблеме.

Половина процесса отладки описана как раз в том треде в форуме. Как видно, я дошел до того, что редиректы с Cicero на Yahoo были практически неотличимы от редиректов с работающего консумера (Dopplr.com под руку первым попался). Я даже написал письмо на support@yahoo.com с просьбой поразбираться с проблемой. Но подозреваю, что оно там канет в лету... Потом решил поискать какой-нибудь более прямой адрес, но вместо этого нашел FAQ по OpenID на Yahoo Developers Network.

Уж не знаю, каким провидением, но я посмотрел на последний пункт, который никоим образом даже не напоминает то сообщение об ошибке, которое я получал. Но именно в нем я нашел ссылку на параграф 13 спецификации OpenID, в котором описан интересный режим, про который я раньше не слышал. Заключается он в том, что когда консумер (Cicero) отправляет юзера редиректом на его сервер (Yahoo), он обязательно указывает в запросе URL, куда надо вернуться (openid.return_to), а также свой "главный" URL (openid.realm). Так вот сервер, оказывается, может сам при этом сходить на URL консумера с запросом "а правда ты поддерживаешь такой вот return_to?" И оказалось, что именно в этом и дело. Несмотря на то, что спецификация разрешает консумерам этого не делать, сервер Yahoo отказывается авторизовывать человека, пришедшего с такого консумера, рисуя при этом совершенно непомогающее сообщение об ошибке.

В общем, я научил Cicero откликаться на такие запросы, выдавая соответствующий XRDS-документ со своего корня:

def index(request, *args, **kwargs):
    if 'application/xrds+xml' in request.META.get('HTTP_ACCEPT', ''):
        return render_to_response(request, 'cicero/yadis.xml', {
            'return_to': absolute_url(reverse(auth)),
        }, mimetype='application/xrds+xml')
    return object_list(request, *args, **kwargs)

Кроме того еще пришлось подпилить Vooid, который перехватывал все XRDS-запросы на сервер, не давая отработать форуму. Теперь перехватывает только свои.

Вообще, Yahoo — известные паранойики в том, что касается OpenID. Но смысл вот этой конкретной фичи от меня ускользает, если честно... Не могу построить в голове сценарий, кто и как может использовать неправильный return_to во вред юзеру.

P.S. А еще меня очень повеселил вот этот кусочек с залогинной страницы OpenID Home:

To make things easy, we have generated this identifier for you: https://me.yahoo.com/a/j78Z.1JlgJKOaoiTbhX0XxMvN8G7gw--

:-)

Комментарии: 8 (feed)

  1. Александр Кошелев

    Слушай, так это называется "relying party verification mechanism", да?

  2. Иван Сагалаев

    Параграф в спеке называется "Discovering OpenID Relying Parties". Но по смыслу твое название тоже подходит.

  3. Александр Кошелев

    Ага. Спасибо.
    Я вот сейчас допиливаю свой консьюмер и тестовый сервер ругается на то, что у меня не поддерживается вот этот самый "relying party verification mechanism". Я понимал, что это что-то связанное с XRDS, но не знал точно куда копать.

  4. Владимир Епифанов

    Всё-таки у Yahoo очень суровый OpenID. У них же ещё поддерживаются только v.2 консьюмеры.

  5. [...] OpenID можно было использовать что угодно. Недавно это пришлось оторвать, да, в общем-то, оно ни разу и не пригодилось. Так что [...]

  6. Григорий Петухов

    Хм, а у меня без всяких ухищрений авторизация через yahoo работает. Вернее работает на сервере. А вот дома чего-то не то происходит, я ещё не разбирался. Факт, что на сервере без описанных в статье плясок работает.

  7. Сергей Бейлин

    Интересно, а с Rambler - работает? ;) Так вот сходу у меня с python-openid возникли некоторые проблемы, например:

    Endpoint mismatch: Claimed ID does not match (different subjects!), Expected id.rambler.ru/users/XXX, got http://id.rambler.ru/users/XXX

Добавить комментарий

Format with markdown