2010-01-17 2 views
0

Я думал, я понял, как работает Open ID, но теперь я запутался ...Запуск запроса на стороне клиента на сервере

FYI, я не пытаюсь понять, как использовать Open ID в качестве разработчика , а скорее фактические действия, которые он использует для аутентификации через браузер клиента.

Как я понял, пользователь (например) выбирает Google в качестве поставщика Open ID. Затем сервер запрашивает предопределенный URL-адрес, предоставленный третьей стороной Open ID. Этот запрос отправляется через браузер клиента, и ответ возвращается серверу. Если ответ равен «подписанному», пользователь не знает о какой-либо активности в своем браузере, кроме как попасть на страницу «приветствия» на главном сайте. Если ответ равен «никто не подписался», браузер открывает новое окно с экраном входа для третьей стороны.

Итак, как на странице входа в систему Open ID действительно отправляется запрос третьей стороне для получения ответа? Нужно ли всегда запрашивать запрос через клиентский скрипт, т. Е. Javascript/ajax, или может быть отправлен запрос с сервера на браузер без какого-либо javascript?

ответ

3

Предлагаю вам прочитать the spec.

Вкратце (это не совсем точно, но большая часть потока есть) полагающаяся сторона (также как RP: сайт, к которому пользователь пытается войти) строит URL-адрес, содержащий сообщение, которое RP хочет отправьте поставщику OpenID (OP), который описывает сам RP и какой логин он хочет, чтобы пользователь прошел. RP отправляет 301 сообщение Redirect в браузер, чтобы браузер был направлен на этот URL-адрес, созданный RP. Браузер отправит этот URL в OP, поэтому OP получит сообщение. Ответ OPs на браузер будет либо HTML-страницей, чтобы пользователь мог войти в OP, либо переадресовать 301 с помощью тщательно обработанного URL-адреса, который отправляет браузер обратно в RP с сообщением, сообщающим RP «да», этот пользователь зарегистрирован как x ".

RP проверяет, что сообщение из OP является geniune либо путем проверки подписи OP, включенной в сообщение, используя общий секрет между RP и OP, либо путем отправки прямого HTTP-сообщения от RP к OP, запрашивающего «Ты послал это?»

Обратите внимание, что здесь не задействованы AJAX или любые формы скриптов.

Теперь в некоторых расширенных сценариях используется AJAX , но во всех случаях общий поток информации между RP и OP и браузером одинаковый. Речь идет только о том, происходят ли некоторые из этих «перенаправлений» в скрытых фреймах через Javascript или нет. И скрытые iframe, конечно, потерпят неудачу, если пользователь не разрешил OP автоматически регистрировать пользователя в этом RP в прошлом.

+0

Я просто подумал: «Я должен внимательно прочитать спецификацию», прежде чем я увижу ваш ответ. Спасибо! Переадресация, предварительная авторизация, скрытые iFrames. Это те компоненты, которых я не получал вообще. Я думал, что все происходит на стороне сервера через некоторые готовые библиотеки и что сервер каким-то образом разговаривает прямо в браузере. Я определенно все еще теряюсь в реальной версии, но это отличное начало. – Anthony

1

Библиотека openidenabled фактически выплескивает очень простую страницу html, состоящую из формы с некоторым javascript для автоматической отправки формы и перенаправления. Когда javascript не используется, форма распечатывается, и пользователь может нажать кнопку отправки.

Смежные вопросы