Веб-разработка часто требует столкновения с междоменными проблемами. Коренной причиной проблем междоменов является та же оригинальная стратегия в безопасности браузера. Например, для http://www.a.com/1.html:
1. http://www.a.com/2.html гомологично;
2. https://www.a.com/2.html из разных источников, потому что протокол отличается;
3. http://www.a.com:8080/2.html из разных источников, потому что порты разные;
4. http://sub.a.com/2.html из разных источников, потому что хосты разные.
В браузере теги <script>, <img>, <iframe> и <Link> могут загружать кросс-домен (не-гомологичные) ресурсы, а метод загрузки фактически эквивалентен обычному запросу GET. Единственное отличие состоит в том, что ради безопасности браузер не разрешает операции чтения и записи на загруженных ресурсах таким образом, но может использовать только те возможности, которые должна иметь сама тег (например, выполнение скрипта, приложение стиля и т. Д.).
Наиболее распространенной проблемой междоменной является задача AGAX по междоменному доступу. По умолчанию через Ajax нельзя получить междоменные URL. Здесь я записываю то, что узнал о междоменных методах:
1. Прокси на серверной стороне , нечего сказать. Недостатком является то, что по умолчанию сервер, который получает запросы AJAX, не может получить IP и UA клиента.
2. iframe , использование iframe фактически эквивалентно открытию новой веб -страницы. Специфический метод перекрестного домена-это примерно родительская страница, открываемая доменом, гнездящимися, указывающая на домен B, а затем подчиняет данные. После завершения сервер B может:
● Вернуть отклик 302 перенаправления и укажите результат обратно в домен A;
● Гнездо, что iframe, указывающая на домен A в этом iframe.
Оба из них наконец-то реализуют междоменные вызовы. Этот метод более функционально сильнее, чем JSONP, введенный ниже, потому что после завершения перекрестного домена нет проблем с операциями DOM и вызовов JavaScript между друг другу, но существуют некоторые ограничения, такие как результат, передаваемые в параметрах URL, что означает, что когда данные результата велики, необходимо передавать в сегментации, что является очень проблемным; Есть еще одна проблема, вызванная самой iframe, и взаимодействие между родительской страницей и самой iframe имеет ограничения безопасности.
3. Используйте теги скрипта для перекрестного домена , этот метод также очень распространен. Теги скрипта могут загрузить иностранный JavaScript и выполнять их. Предварительная функция обратного вызова может реализовать взаимодействие с родительской страницей. У него есть громкое название под названием JSONP Cross-Domain, которое является аббревиатурой для JSON с заполнением. Это неофициальный протокол, который, очевидно, загружает сценарий, так почему он связан с JSON? Оказывается, это эта функция обратного вызова. Существует типичный способ его использования, который состоит в том, чтобы пройти параметры через JSON, то есть заполнить данные JSON в функцию обратного вызова. Это смысл JSONP JSON+PADDING.
В Интернете есть много услуг JSONP для предоставления данных. По сути, они представляют собой перекрестные запросы и указывают обратные вызовы в URL-адресе запроса, такие как обратный вызов = результат. После получения этих данных, функция результата будет автоматически вызвана, и данные будут переданы в форме JSON, например (поиск «футбол»):
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=result
Используйте jQuery, чтобы назвать это и написать как:
Кода -копия выглядит следующим образом:
$ .getJson ("http://ajax.googleapis.com/ajax/services/search/web?v=1.0&q=football&callback=?", function (data) {
// ...
});
В целом, ограничение подхода JSONP от JSONP заключается в том, что он может использовать только запросы GET и не может решить проблему того, как сделать вызовы JavaScript между двумя страницами в разных областях.
4. Flash Cross-Domain:
Он будет получить доступ к файлу CrossDomain.xml в рамках корневого каталога целевого веб-сайта и определит, разрешать ли этот перекрестный доступ на основе содержимого в файле:
Кода -копия выглядит следующим образом:
<Кросс-домен-политика>
<allow-ccess-from domain = "xxx.xxx.com" />
</cross-domain-policy>
5. Также можно использовать метку IMG , что также является очень распространенным методом. Он имеет более слабую функцию и может отправлять запрос GET только без каких -либо обратных вызовов. Так определяется количество кликов Google.
6. window.postmessage, который является недавно добавленным механизмом для междоменной связи, поддерживается только Firefox 3, Safari 4, IE8 и более поздними версиями. Вызов для использования его для отправки сообщений в другие окна выглядит следующим образом:
Кода -копия выглядит следующим образом:
Другой window.postmessage (сообщение, Targettorigin);
В приемном окне необходимо установить обработчик событий для получения отправленных сообщений:
Кода -копия выглядит следующим образом:
window.addeventListener ("Сообщение", GetiveMessage, false);
функция receiveMessage (event) {
if (event.orgin! == "http://example.org:8080")
возвращаться;
}
Обратите внимание, что исходные атрибуты сообщения должны использоваться для проверки личности отправителя, в противном случае это приведет к уязвимости XSS.
7. Контроль доступа
Некоторые браузеры поддерживают заголовки откликов, такие как контроль доступа, авооригин, такие как:
Кода -копия выглядит следующим образом:
Header ("Access-Control-llow-Origin: http://www.a.com");
Это определяет, что доступ к перекрестному домену к www.a.com разрешен.
8. window.name
Эта вещь на самом деле использовалась в качестве средства для взлома XSS. Суть заключается в том, что при изменении местоположения окна страница будет перезагружена, но, что интересно, окно. С помощью iframe измените окно-объект IFRAME несколько раз, и практическая передача данных междомена завершена.
9. Document.domain
Этот метод подходит для междоменной связи, такой как A.Example.com и B.Example.com, потому что они имеют общий домен под названием example.com. Просто установите Document.domain to example.com, но если вы хотите общаться между A.Example1.com и B.Example2.com, у него нет выбора.
10. Фрагмент идентификатор обмена сообщениями (FIM)
Этот метод очень интересный и требует сотрудничества IFRAMES. Fragment Identier - это та часть, которая часто используется для позиционирования якоря после отметки фунта URL (#). Изменения в этой части не приведут к обновлению страницы. Женское окно может получить доступ к URL IFRAME по желанию, и iframe также может получить доступ к URL -адресу женского окна. Затем связь может быть достигнута путем изменения идентификатора Fragmement. Недостатком является то, что изменения в идентификаторе Fragmement будут генерировать ненужную историю и иметь ограничения длины; Кроме того, некоторые браузеры не поддерживают событие Onhashchange.
11. Cross Frame (CF)
Этот метод является вариантом приведенного выше метода FIM. Суть CF и FIM фактически представлена в моей статье «GWT First Experience» (он просто используется для реализации истории и обратных функций). Это динамически создаст невидимый iframe, указывая на внешний домен. После обработки фрагмент идентификатор в URL -адресе этого iframe содержит результаты обработки для родительской страницы, в то время как URL -адрес браузера не имеет изменений.
12. Cookie+P3p протокол
Использование характеристик куки-файлов поперечного домена в соответствии с протоколом P3P для достижения междоменного доступа также является странным трюком. P3P - это стандарт рекомендации по защите конфиденциальности, выпущенный W3C, направленным на то, чтобы обеспечить защиту конфиденциальности для пользователей Интернета, которые занимаются серфингом в Интернете. Установите путь cookie на «/», то есть нет ограничения домена. В настоящее время некоторые браузеры позволяют читать страницы других URL -адресов, а другие - нет. В этом случае заголовок P3P должен быть установлен на главе ответа родительской страницы:
Кода -копия выглядит следующим образом:
P3P: CP = "Cura Adma Deva PSAO PSDO наша автобусная Uni Pur int dem pre com nat otc noi dsp cor"