2013-03-01 3 views
5

Предположим, что я управляю двумя доменами, www.api_domain.com и www.website_domain.com. www.api_domain.com предлагает API, который требует от пользователя аутентификации, а затем использует куки-файл сеанса для распознавания пользователя, делающего запросы. www.website_domain.com загружает скрипт на свои страницы с www.api_domain.com, и этот скрипт хочет совершать вызовы по URL-адресам API на www.api_domain.com с файлом cookie текущего пользователя и использовать результаты каким-то образом на странице с www.website_domain.com.Периферийные файлы cookie в IE 8 и 9 без iframe?

Для первоначальной загрузке сценария, или для каких-либо API URL-адресов, которые не требуют пользователя куки сессии, чтобы работать, самым простым решением является просто использовать заголовок

Access-Control-Allow-Origin: http://www.website_domain.com 

на ответ от www.api_domain.com. Похоже, что это работает извне во всех браузерах, кроме IE, и хотя IE не будет уважать заголовок Allow-Origin на AJAX-запросах, созданных с использованием jQuery-AJAX-методов, есть библиотеки типа xdr.js, которые делают некоторые магии за кулисами make jQuery, IE и заголовок Allow-Origin играют хорошо вместе и ведут себя как во всех других браузерах (я не знаю подробностей о том, что делает xdr.js, но он отлично работает для не-учетных запросов, насколько я могу видеть).

Проблема возникает, когда я хочу нажать URL-адрес на http://www.api_domain.com, для которого требуется файл cookie сеанса пользователя. Когда эта проблема обсуждается в настройки браузера агностиком, как правило, предлагаются два решения:

  1. Использование Access-Control-Allow-Credentials: true на ответ от сделать печенье быть отправлены даже с кросс-доменных запросов.
  2. Создать IFRAME на странице на http://www.website_domain.com с началом http://www.api_domain.com, имеют два окна общаться с друг друга, используя HTML5 post messages и делегировать все ответственность за принятие запросов на http://www.api_domain.com к IFrame.

Я очень предпочитаю использовать вариант 1, если это возможно, так как он позволяет писать код Javascript, чтобы использовать API на http://www.api_domain.com таким же образом, как вы пишете его трогать тот же домен API. Чтобы использовать подход iframe, нам нужно изучить или создать некоторую инфраструктуру для отправки AJAX-подобных запросов в iframe с успехами и обработчиками ошибок. Это также означает, что нам нужно создать код для загрузки в iframe, который будет всего лишь целым куском тонких оберток для попадания URL-адресов API. Это кажется более уродливым, сложнее и труднее понять, чем первый подход.

Однако я не могу понять, как сделать вариант 1 работой над IE. Я устанавливаю Access-Control-Allow-Credentials: true по моим URL-адресам API, а все другие браузеры отправляют файлы cookie на эти URL-адреса, но IE 9 не работает даже с библиотекой xdr.js. (Я не тестировал IE 8). Никаких других симптомов не сообщать. Я могу видеть заголовки Access-Control-Allow-Origin и Access-Control-Allow-Credentials в ответах от www.api_domain.com, когда я просматриваю их в инструментах разработчика IE, но в запросе нет заголовков файлов cookie.

Есть ли какие-то хаки или магические заклинания, которые я могу использовать, чтобы обозреватель Internet Explorer уважал заголовок Access-Control-Allow-Credentials, или какой-нибудь другой заголовок, который я могу использовать, который распознает IE?

+1

Помогает ли настройка политики конфиденциальности p3p? http://stackoverflow.com/questions/2666376/copying-cookies-cross-domain-why-is-ie-blocking-cookies-other-browsers-are-send?rq=1 – flup

+0

@flup Нет, это совершенно не имеет отношения к это. –

+0

В стороне, которая не помогает ответить на этот вопрос, но, вероятно, будет полезной для всех, кто ее читает: вместо того, чтобы создавать собственный прокси-сервер iframe, учитывая использование этой библиотеки (https://github.com/jpillora/xdomain/) , Я не тестировал его, но похоже, что он должен прозрачно выполнять всю работу по проксированию междоменного трафика AJAX через почтовое сообщение для вас. Если вы не нуждаетесь в поддержке supercookie для обработки растущего числа браузеров, которые по умолчанию блокируют «сторонние» файлы cookie (в том числе установленные в iframe), он должен быть адекватным. –

ответ

9

Вариант 1 невозможен в IE9 или ниже, потому что поддержка CORS с помощью XMLHttpRequest отсутствует. Кроме того, если вы попытаетесь использовать XDomainRequest, вы никогда не сможете отправлять куки вместе с вашим запросом. Я несколько раз по этой дороге работал над написанием библиотеки тестирования ui, которая будет использоваться с testwarm. То, что вы хотите сделать, просто невозможно.

Вот пост Эрика закон, разработчик экс-Microsoft, обсуждая этот вопрос в деталях: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

Соответствующие разделы, которые делают ясно, что отправку печенья с запросом CORS невозможно в IE 8 и 9, являются следующими:

В Internet Explorer 8 был введен объект XDomainRequest. Этот объект позволяет приложениям AJAX делать безопасные кросс-начальные запросы напрямую, гарантируя, что HTTP-ответы могут быть прочитаны только текущей страницей, если источник данных указывает, что ответ является общедоступным; таким образом, защита безопасности одной и той же исходной политики защищена. Ответы указывают на их готовность разрешать доступ к перекрестным доменам, включая заголовок ответа HTTP Access-Control-Allow-Origin со значением * или точное происхождение вызывающей страницы.

При проектировании нового объекта нашим главным приоритетом было бы обеспечение того, чтобы существующие сайты и службы не подвергались риску. С этой целью мы наложили ряд ограничений на то, какие запросы могут быть сделаны с объектом XDomainRequest.

...

5: Проверка подлинности или печенье будет отправлено с просьбой

В целях предотвращения неправомерного использования окружающей среды полномочий пользователя (например, печенье, учетные данные HTTP, клиентские сертификаты и т.д.), запрос будет лишен файлов cookie и учетных данных и будет игнорировать любые проблемы с проверкой подлинности или директивы Set-Cookie в ответе HTTP. XDomainRequests не будет отправляться по ранее аутентифицированным соединениям, поскольку некоторые протоколы проверки подлинности Windows (например, NTLM/Kerberos) основаны на каждом соединении, а не на основе запроса.

Сайты, которые хотят выполнить аутентификацию пользователя для запросов с кросс-началом, могут использовать явные методы (например, токены в модуле POST или URL-адресе), чтобы передавать эту информацию аутентификации, не рискуя полномочиями пользователя.

Теперь если вы контролировать оба место, вы могли бы предположительно создать сервер для процесса аутентификации сервера и идти о передаче идентификатора сеанса сортов, предоставляемых из домена для другого домена, из которого клиент фактически на счет ваш запрос. Это некрасиво, но это работает. Этот метод также упоминается в статье. Вы захотите быть осторожными, потому что это открывает возможность захвата сеанса.

+0

Удивительная ссылка, спасибо. Ясно, что это невозможно. Авто-сервер от сервера к серверу кажется еще более clunkier решением, чем использование iframe, поэтому я буду придерживаться решения iframe. –

0

У IE8 + есть альтернатива XMLHttpRequest, которая поддерживает учетные данные XDomainRequest.в любом случае, XDomainRequest не реализован JQuery, поскольку он имеет меньше функциональности, чем тот, который предоставляется XMLHttpRequest, но есть плагин, например jQuery CORS Plugin, который обеспечивает то, что вам нужно.

JQuery плагин, который добавляет прозрачно Cross Origin Sharing (CORS) ресурсов среди браузеров, включая Internet Explorer 8 +, чтобы Междоменные Ajax запросы с печеньем и заголовки поддержки.

также я думаю, но не уверен, что IE не поддерживает подстановочные знаки в заголовках, например Access-Control-Allow-Origin: *.

+0

Мы не используем подстановочные знаки; вы не можете использовать подстановочные знаки с учетными запросами в любых браузерах, которые я видел в любом случае, согласно спецификации CORS. Рефери github, с которым вы связаны, выглядит многообещающим, но я немного смущен. Там есть Java и Javascript, и никаких инструкций по использованию; идея о том, что Javascript работает только в сочетании с материалом Java, используемым серверами для обработки запросов? –

+0

На самом деле, я еще не попробовал, я думаю, что Java предназначен только для тестирования на стороне сервера. вы также можете проверить это https://github.com/MoonScript/jQuery-ajaxTransport-XDomainRequest –

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