Вопрос о междоменном (subdomain) ajax-запросе

Question

Предположим, у меня есть основная страница, загруженная с http://www.example.com/index.html. На этой странице есть js-код, который делает запрос ajax на http://n1.example.com//echo?message=hello. Когда ответ получен, div на главной странице обновляется с телом ответа.

Будет ли это работать на всех популярных браузерах?

Edit:

Очевидное решение поставить прокси перед www.example.com и n1.example.com и установите его так, что каждый запрос собирается на subresource из http://www.example.com/n1 получает проксированном к http://n1.example.com/.

Answer 1

Другим решением, которое может или не может работать для вас, является динамическое вставка/удаление тегов сценариев в DOM, которые указывают на целевой домен. Это будет работать, если цель возвращает json и поддерживает обратный вызов.

Функция для обработки результата:

<script type="text/javascript"> 
    function foo(result) { 
    alert(result); 
    } 
</script> 

Вместо того чтобы делать запрос AJAX вы динамически вставить что-то вроде этого:

<script type="text/javascript" src="http://n1.example.com/echo?callback=foo"></script> 

Answer 2

другой обходной путь, чтобы направить запрос AJAX к PHP (например) в вашем домене, и на этой странице сделать запрос cURL субдомену.

Answer 3

Перекрестный домен - это совсем другой предмет. Но кросс-поддомен относительно прост. Все, что вам нужно сделать, - установить для document.domain одинаковые как на родительской странице, так и на странице iframe.

document.domain = "yourdomain.com" 

More info here

Примечание: этот метод will only let you interact with iframes from parents of your domain. Он не изменить источник, отправленный XMLHttpRequest.

Answer 4

Новая идея: если вы хотите перекрестный субдомен (www.domain.com и sub.domain.com), и вы работаете над apache. вещи могут стать намного проще. если субдомен фактически является подкаталогом в public_html (sub.domain.com = www.domain.com/sub/. поэтому, если у вас есть ajax.domain.com/?request=subject..., вы можете сделать что-то вроде этого: www .domain.com/Ajax /? = запрос предмет

работает как шарм для меня, и не тупых писак, доверенности или трудных вещи, чтобы сделать всего несколько запросов Ajax!

Answer 5

Я написал решение для кросса . поддомен и его работает для моих приложений я использовал IFRAME и установка document.domain = «domain.com» на обеих сторонах Вы можете найти свое решение по адресу:.

https://github.com/emphaticsunshine/Cross-sub-domain-solution

Answer 6

Простейшим решением, которое я нашел, было создание php на вашем поддомене и включение в него исходного файла функции с использованием полного пути.

Пример:

www.domain.com/ajax/this_is_where_the_php_is_called.PHP

Subdomain:

sub.domain.com

Создать: sub.domain.com/I_need_the_function.php

Внутри I_need_the_function.php просто использовать a включают:

include_once ("/ server/path/public_html/ajax/this_is_where_the_php_is_called.php");

Теперь вызовите sub.domain.com/I_need_the_function.php с вашего javascript.

var sub=""; 
switch(window.location.hostname) 
{ 
case "www.domain.com": 
sub = "/ajax/this_is_where_the_php_is_called.php"; 
break; 
case "domain.com": 
sub = ""; 
break; 
default: ///your subdomain (or add more "case" 's) 
sub = "/I_need_the_function.php"; 
} 


xmlHttp.open("GET",sub,true); 

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

Я надеюсь, что это поможет кому-то. Здесь нет ничего грязного - и вы вызываете исходный файл, поэтому любые изменения будут применяться ко всем функциям.

Answer 7

Все современные браузеры поддерживают CORS, и отныне мы должны использовать это дополнение.

Он работает на простой технике рукопожатия, поскольку 2 домена обмениваются доверием друг друга посредством HTTP-заголовков, отправленных/полученных. Это было долгождано, поскольку одна и та же политика происхождения была необходима, чтобы избежать XSS и других вредоносных попыток.

Чтобы инициировать запрос перекрестного происхождения, браузер отправляет запрос с помощью HTTP-заголовка Origin. Значение этого заголовка - это сайт, который обслуживал страницу. Например, предположим, что страница на http://www.example-social-network.com пытается получить доступ к данным пользователя в онлайн-альбоме-calendar.com. Если браузер пользователя реализует CORS, следующий заголовок запроса будет отправлен:

Происхождение: http://www.example-social-network.com

Если online-personal-calendar.com позволяет запрос, он посылает заголовок Access-Control-Allow-Origin в его ответ. Значение заголовка указывает, какие исходные сайты разрешены. Например, в ответ на предыдущий запрос будет содержать следующее:

Access-Control-Allow-Origin: http://www.example-social-network.com

Если сервер не разрешает запрос кросс-происхождения, браузер будет поставлять ошибку example-social-network.com вместо ответа online-personal-calendar.com.

Чтобы разрешить доступ ко всем страницам, сервер может отправить следующий заголовок ответа:

Access-Control-Allow-Origin: *

Однако, это может быть не подходит для ситуаций, в которых безопасность беспокойство.

Очень хорошо объяснено здесь на странице wiki. http://en.wikipedia.org/wiki/Cross-origin_resource_sharing