Я хотел создать вики сообщества относительно HTML/JS политики одинакового происхождения, чтобы, надеюсь, помочь всем, кто ищет эту тему. Это одна из самых часто запрашиваемых тем на SO, и для нее нет консолидированной вики, так что я здесь :)
Политика одинакового происхождения не позволяет документ или скрипт, загруженный из одного происхождения от получения или установки свойства документа из другого происхождения. Эта политика берет свое начало еще с Netscape Navigator 2.0.
Пожалуйста, приводите примеры в развернутом виде и, желательно, указывайте ссылки на источники.
Обратите внимание, что это способ iframe, который устанавливает значение документа.домен с суффиксом текущего домена. Если это так, то чем короче домен используется для последующих проверок происхождения. Например, предположим, что скрипт в документ на http://store.company.com/dir/other.html` выполняет следующее заявление:
document.domain = "company.com";
После этого оператор выполняется, то страница будет пройти проверку происхождения с http://company.com/dir/page.html. Однако, по тем же соображениям company.com не мог установить документ.домен
в othercompany.com
.
С помощью этого метода, вам будет позволено exectue JavaScript-код из iframe получены на поддомене на странице продуктов на основной домен. Этот метод не подходит для кросс-доменных ресурсов, как браузеры, такие как Firefox не позволит вам изменить документ.домен к абсолютно чужой домен.
Источник: https://developer.mozilla.org/en/Same_origin_policy_for_JavaScript
Кросс-происхождения совместное использование ресурсов (ПДБС) - рабочий проект консорциума W3C, которая определяет, как браузер и сервер должны общаться, когда доступ к источникам по происхождению. Основная идея CORS для использовать пользовательские заголовки HTTP, чтобы оба браузера и сервера, чтобы знать достаточно о друг с другом, чтобы определить, если запрос или ответ должны преуспеть или потерпеть неудачу.
Для простого запроса, который использует GET
или пост
без пользовательских заголовков и чье тело текст/равнина
, то запрос направляется с дополнительным заголовком под названием "Происхождение". Заголовок происхождения содержит источника (протокол, доменное имя и порт) запрашивающего страницу, так что сервер может легко определить, является ли или не оно должно служить ответом. Пример происхождения
заголовок может выглядеть так:
Origin: http://www.stackoverflow.com
Если сервер решает, что запрос должен быть разрешен, он посылает контроля доступа-разрешить-происхождение заголовка
поддакивания и того же происхождения, которое было отправлено или*
, если это общественный ресурс. Например:
Access-Control-Allow-Origin: http://www.stackoverflow.com
Если этот заголовок отсутствует, или происхождение не совпадают, то браузер блокирует запрос. Если все хорошо, то браузер обрабатывает запрос. Обратите внимание, что ни запросы, ни ответы включают информацию cookie.
Команда Mozilla предлагает в их пост о CORS, что вы должны проверять наличие имущества withCredentials
, чтобы определить, если браузер поддерживает технологии CORS через XHR. Затем можно пару с существованием XDomainRequest
объект для покрытия всех браузерах:
function createCORSRequest(method, url){
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr){
xhr.open(method, url, true);
} else if (typeof XDomainRequest != "undefined"){
xhr = new XDomainRequest();
xhr.open(method, url);
} else {
xhr = null;
}
return xhr;
}
var request = createCORSRequest("get", "http://www.stackoverflow.com/");
if (request){
request.onload = function() {
// ...
};
request.onreadystatechange = handler;
request.send();
}
Обратите внимание, что для метода CORS, чтобы работать, вы должны иметь доступ к любому типу заголовка сервера, механик и может'Т просто доступ к любого стороннего ресурса.
Источник: http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-origin-resource-sharing/
окна.метод postMessage
, при вызове, вызывает MessageEvent
, чтобы быть отправленным в "окно", когда все ожидающие сценарий, который должен быть выполнен завершения (например, оставшиеся обработчики событий, если окно.метод postMessageвызывается из обработчика событий, ранее отложенных таймауты и т. д.). В
MessageEventимеет сообщение типа "данные" свойство, которое устанавливается в строковое значение первого аргумента приводилось в окно.метод postMessage
, свойство происхождения
, соответствующее происхождение основного документа в окне вызова окно.метод postMessageв окно времени
.метод postMessageи
источникаимущество, которое является окно, из которого окна.метод postMessage
называется.
Чтобы использовать "окно".метод postMessage`, прослушиватель событий должны быть приложены:
// Internet Explorer
window.attachEvent('onmessage',receiveMessage);
// Opera/Mozilla/Webkit
window.addEventListener("message", receiveMessage, false);
И receiveMessage функция должна быть объявлена:
function receiveMessage(event)
{
// do something with event.data;
}
Офф-сайт iframe должен также направить события должным образом через метод postMessage`:
<script>window.parent.postMessage('foo','*')</script>
Любое окно может получить доступ к этому методу на любое другое окно, в любое время, независимо от расположения документа в окне, чтобы отправить это сообщение. Следовательно, любой слушатель события, используемый для получения сообщений должны сначала проверить личность отправителя сообщения, используя происхождение и, возможно, свойства источника. Это не может быть занижена: неспособность проверить "происхождение" и, возможно, источник
свойств позволяет межсайтового скриптинга.
Источник: https://developer.mozilla.org/en/DOM/window.postMessage
Установка простого обратного прокси на сервере позволит браузеру использовать относительные пути для Ajax-запросов, в то время как сервер будет действовать как прокси для любого удаленного местоположения.
При использовании mod_proxy в Apache, основной конфигурационной директивой для установки обратного прокси является ProxyPass
. Обычно она используется следующим образом:
ProxyPass /ajax/ http://other-domain.com/ajax/
В этом случае браузер сможет запросить /ajax/web_service.xml
как относительный URL, но сервер будет обслуживать его, действуя как прокси на http://other-domain.com/ajax/web_service.xml
.
Интересной особенностью этого метода является то, что обратный прокси-сервер может легко распределять запросы на несколько внутренних узлов, действуя таким образом как балансировщик нагрузки.
Я использую JSONP.
По сути, вы добавляете
<script src="http://..../someData.js?callback=some_func"/>
на свою страницу.
Должна быть вызвана функция some_func(), чтобы вы были уведомлены о поступлении данных.
AnyOrigin не't функция с некоторым сайтам https, так что я просто написал открытое альтернативный источник назвал whateverorigin.org, что, кажется, хорошо работать с https.
Я могу'т утверждают, кредит на этот образ, но он соответствует всему, что я знаю на эту тему и предлагает немного юмора в то же время.
Самый последний способ преодоления того же происхождения политики, что я'вэ нашел http://anyorigin.com/
На сайте's сделал так, что вы просто дать ему любой URL-адрес и он генерирует код JavaScript/jQuery для вас, что позволяет получить HTML-код/данные, независимо от того, это'происхождение. Другими словами, это делает любой URL-адрес или страница JSONP-запрос.
Я'вэ нашел его очень полезным :)
Здесь's некоторые пример кода JavaScript из anyorigin:
$.getJSON('http://anyorigin.com/get?url=google.com&callback=?', function(data){
$('#output').html(data.contents);
});
В JSONP в приходит на ум:
JSONP или "в JSON с подкладкой" в это В дополнение к базе данных в формате JSON формат использования шаблона, что позволяет страницы запросу и более осмысленно использовать JSON с сервера, чем основной сервер. JSONP является одним альтернатива более поздний способ называется кросс-происхождения совместное использование ресурсов.
Это довольно много анализировать то, что имеется под рукой: http://www.slideshare.net/SlexAxton/breaking-the-cross-domain-barrier
Для решения метод postMessage взгляните на:
https://github.com/chrissrogers/jquery-postmessage/blob/master/jquery.ba-postmessage.js
и немного другая версия:
https://github.com/thomassturm/ender-postmessage/blob/master/ender-postmessage.js
Ну, я использовал curl в PHP, чтобы обойти это. У меня есть веб-сервиса, запущенного в порт 82.
<?php
$curl = curl_init();
$timeout = 30;
$ret = "";
$url="http://localhost:82/put_val?val=".$_GET["val"];
curl_setopt ($curl, CURLOPT_URL, $url);
curl_setopt ($curl, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt ($curl, CURLOPT_MAXREDIRS, 20);
curl_setopt ($curl, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($curl, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5");
curl_setopt ($curl, CURLOPT_CONNECTTIMEOUT, $timeout);
$text = curl_exec($curl);
echo $text;
?>
Вот JavaScript, который вызывает php-файл
function getdata(obj1, obj2) {
var xmlhttp;
if (window.XMLHttpRequest)
xmlhttp=new XMLHttpRequest();
else
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
xmlhttp.onreadystatechange=function()
{
if (xmlhttp.readyState==4 && xmlhttp.status==200)
{
document.getElementById("txtHint").innerHTML=xmlhttp.responseText;
}
}
xmlhttp.open("GET","phpURLFile.php?eqp="+obj1+"&val="+obj2,true);
xmlhttp.send();
}
Мой HTML-код работает на ПУВР в порт 80. Так что мы идем, же политику происхождения было обойти :-)
Вот некоторые решения и объяснения того же источника-политики: Тиру's блоге - браузера того же происхождения политики Решение
Лично я считаю window.postMessage
самым надежным способом, который я нашел для современных браузеров. Вам придется проделать немного больше работы, чтобы убедиться, что вы не оставляете себя открытым для XSS-атак, но это разумный компромисс.
Существует также несколько плагинов для популярных наборов инструментов Javascript, которые оборачивают window.postMessage
и обеспечивают аналогичную функциональность для старых браузеров, используя другие методы, рассмотренные выше.