AJAX, поддомены и SSL

Большинство браузеров, в зависимости от настроек безопасности / конфиденциальности, блокируют любые внешние вызовы - и разрешают только вызовы AJAX в один и тот же домен. Блокируются даже поддомены, потому что в общих средах они могут представлять реальную угрозу.

Вкратце: выполняйте вызовы AJAX только через один и тот же домен (возможно, вызывайте страницу, которая, в свою очередь, вызывает другую страницу из другого домена - через curl / fopen / ...), или вы столкнетесь с проблемами. Это также отвечает на ваш вопрос об SSL - неважно, какой SSL вы используете или одинаковы ли они - вызовы будут заблокированы, несмотря на SSL.

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

Вы можете настроить веб-сервер для foo.com, и вы можете открыть порт 80 для незащищенного и порт 443 для безопасного и использовать оба.

Вы можете настроить другой веб-сервер для bar.foo.com и выполнить те же настройки портов.

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

Возможно, вы сможете купить сертификат * .foo.com, который позволит вам скопировать один сертификат на другой сайт и использовать его.

Независимо от того, ссылается ли ваш запрос на http://bar.foo.com, у вас не будет безопасного соединения.

У вас должен быть http «s», чтобы указать веб-серверу использовать порт 443 и попытаться проверить сертификат.

Все сертификаты действительно говорят о том, что источнику доверяют. Даже если ему не доверяют, и вы используете http "s", а браузер заблокирован, ваши данные все равно зашифрованы.

С обычным http AJAX: вы говорите о выполнении междоменного XMLHttpRequest, что не разрешено браузерами. Существует Предложение W3C на рассмотрении для безопасной реализации этого в будущем (частично реализованный IE8, IIRC), но в настоящее время это определенно невозможно.

Однако есть обходные пути для обеспечения безопасности: Подпространство (который использует iframe и document.domain), метод идентификатора фрагмента (опять же, использует iframe) и window.name техника (опять же iframe!).

Что касается SSL, вы можете купить отдельные сертификаты для домена и субдомена или один сертификат с подстановочными знаками (* .foo.com), который покрывает их оба (естественно, сертификат с подстановочными знаками будет дороже).

Если у вас есть страница HTTPS, которая запрашивает элементы из других доменов, все будет хорошо, если все будет HTTPS. Это означает, что если вы используете один из обходных путей iframe, вам необходимо указать URL-адрес схемы https:// в атрибуте src iframe.

Последний, менее эффективный обходной путь - иметь сценарий на https://foo.com, который передает запросы на небезопасный http://bar.foo.com. (Это также решает междоменную проблему XHR, поэтому вы можете игнорировать другие обходные пути.) Конечно, это означает, что вы отправляете запрос XHR на https://foo.com/someurl, затем он отправляет http://bar.foo.com/someurl, получает ответ и отправляет его обратно в браузер. , поэтому с точки зрения производительности вам будет гораздо лучше просто переместить серверную функциональность bar.foo.com на foo.com, если у вас есть такая возможность. Но если вы не можете переместить серверный скрипт, тогда вам подойдет проксирование.

Обновлено: Я изменил последние 3 графа после дополнительного тестирования и получения обходного пути iframe AJAX (#fragmentidentifier) ​​для работы в разных доменах HTTPS. Вы может выполняете междоменный SSL AJAX с использованием iframe, если все является https, а схема https используется в iframe src. Резюмируя:

1. Краткий ответ: нет, истинный междоменный XHR не разрешен
2. Обходной путь с iframe: более эффективно, требуется 2 SSL сертификаты (или сертификаты с подстановочными знаками), несколько сложный
3. Обходной путь с прокси: менее эффективен, можно использовать 1 или 2 SSL-сертификаты (1 с внутренним запросом на bar.foo.com через http), несколько сложный

Вы можете комбинировать JavaScript TLS и Flash для выполнения безопасных междоменных запросов. Таким образом, ваши посетители переходят на https://foo.com, а вы можете делать XmlHttpRequests на https://bar.foo.com. То же самое можно сделать и с обычным http.

Вам нужно будет приобрести SSL-сертификат, которому браузеры вашего посетителя будут доверять для foo.com, но вы можете сгенерировать свои собственные SSL-сертификаты для bar.foo.com, bar2.foo.com и т. д. Более дорогая альтернатива созданию собственного SSL-сертификаты (которые бесплатны) - это покупка подстановочного SSL-сертификата для * .foo.com. Но если вы делаете междоменные запросы к этим сайтам только через foo.com, вам не нужно тратить лишние деньги.

Посмотрите проект Forge с открытым исходным кодом на github:

http://github.com/digitalbazaar/forge/blob/master/README

Ссылки на блог в конце предоставляют более подробное объяснение.

Да, вы, безусловно, можете выполнять кросс-доменные отправки ajax. Мы проделали ту же настройку, используя ssl.com wildcard cert, но вы можете использовать 2 стандартных сертификата на 2 сайтах.

В основном вы должны использовать JSONP (yahoo, google, fb и т. д. Используют это). Возвращаемое значение заключено в функцию, которая выглядит так:

someFunction("{...}");