Междоменный XHR / AJAX: возможный обходной путь? - PullRequest
Новая
       1

Междоменный XHR / AJAX: возможный обходной путь?

3 голосов
/ 02 августа 2011

У меня только что появилась идея совершать междоменные вызовы AJAX, потому что до сих пор они действительно были PITA для работы. Это решение, которое я не видел нигде в Интернете, поэтому оно может быть (вероятно, ошибочно) по какой-то причине, чего я сейчас не вижу, поэтому я обращаюсь к вам, чтобы сказать мне если это законно или нет:

Сегодня, если у вас есть домен www.foo.com, вы не можете отправлять запросы XML Http на адрес www.bar.com. Но что, если вы сделали XHR для foo.com, тогда бы запросили страницу bar.com через запрос cURL (или сокет, или что-то еще?).

Вы обычно настраиваете свой xhr, будь то GET или POST, но вместо этого отправляете его на foo.com/remote-xhr.php и добавляете параметр «url», содержащий первоначально предназначенный URL, и «params» параметр, содержащий, ну, параметры.

remote-xhr.php анализирует «params», вызывает «url» и «echo» ответ.

Это определенно компромисс, потому что: 1. вы делаете 2 вызова вместо одного с другими решениями (скрипт тэг hack / JSONP) и 2. вы теряете любую аутентификацию, которая у вас могла быть, потому что клиент не запрашивает страницу, но сервер есть (вы можете обойти его с помощью уникальных идентификаторов, соли, чего угодно); но тогда у вас будет совершенно нормальный вызов XHR, который может работать с любым другим доменом!

Чего мне не хватает?

Ответы [ 3 ]

2 голосов
/ 02 августа 2011

Полагаю, вы уже подумали о некоторых из них, но на всякий случай не

  1. Если вы не проводите какую-либо аутентификацию с помощью вашего XHR-доступа на стороне сервера, вы можете захотеть ограничить то, какие URL-адреса можно вызывать, и проанализировать параметры для любых необычных возможностей XSS, которые это предоставляет.

  2. Увеличение задержки может создать нагрузку на ваш веб-сервер, поскольку он может дольше удерживать потоки запросов / ответов в ожидании ответа cURL на возвращение (если вы не выполняете какую-то дополнительную асинхронную архитектуру). Кэширование ответа cURL может быть предпочтительнее, но в зависимости от того, сколько вариантов ваших параметров POST вы можете встретить, это не может быть вариантом.

Я уверен, что есть другие, зависящие от вашего приложения, но я пойду дальше и скажу, что я делаю что-то подобное, но только потому, что я плачу за внешний API, который я не хочу выставлять напрямую моему Приложение AJAX ... так что я довольно сильно абстрагировал звонки и ограничил их одним внешним URL-адресом.

1 голос
/ 02 августа 2011

Это работоспособно, но имейте в виду, что вы разрешаете клиенту вашему сообщать, какие данные загружать. В зависимости от вашей реализации, это может быть довольно безобидно, но может легко укусить вас в задницу, если оно не защищено (возможно, ограничить его очень конкретными доменами?).

Например, кто-то может отправить несколько запросов вашему обработчику, который возвращает, скажем, ISO-образ Linux или что-то незаконное.

1 голос
/ 02 августа 2011

Ничего плохого в этом нет. Я использую этот трюк в своих AJAX-запросах.

...