Есть ли способ обойти ту же политику происхождения Javascript / jQuery для локального доступа?

Question

Попытка использовать ajax, getJSON и подобные функции для извлечения внешнего URL-адреса с локального (не серверного) компьютера разработки. Есть ли способ обойти ту же политику происхождения, чтобы я мог проводить локальное тестирование вместо загрузки на сервер?

Answer 1

Вот простой ответ: chrome --disable-web-security

Из исходного кода (chrome_switches.h):

// Don't enforce the same-origin policy.  (Used by people testing their sites.)
const char kDisableWebSecurity[]            = "disable-web-security";

Я хотел использовать jquery.js для отправки вызовов AJAX на сервер Python Служб Google, работающий через порт 8080. Просто для тестирования я хотел запустить браузер и сервер на одной машине.

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

Вот вся команда для Mac OS X:

/ Приложения / Google \ Chrome.app/Contents/MacOS/Google \ Chrome --disable-web-security

Answer 2

У нас была такая же потребность при разработке нашего веб-приложения. Вот как мы это сделали:

Браузер и сервер взаимодействуют только через JSON.
Весь HTML-код отображается в браузере с использованием PURE (наш шаблонизатор JS).
Код браузера разрабатывается локально так:

Мы добавляем параметр host в URL приложения:

http://localhost/app.html?host=test.beebole-apps.com

При работе JSON отправляются на сервер с POST.
Но здесь функция, отвечающая за вызов ajax, будет реагировать на параметр host и вместо этого делать JSONP инъекцию (GET).

<script src="http://test.beebole-apps.com/?callback=f2309892&json={...}" />

• f2309892 - это временная функция со случайным именем, указывающая на метод, который будет обрабатывать ответ
• json - это JSON, который мы отправляем на сервер

Это означает, что вам понадобится некоторое сотрудничество со стороны бэкэнда, чтобы предоставить вам json, завернутый в функцию обратного вызова, например:

f2309892( /*the json here*/ );

За исключением ограничения размера (вы не можете отправить большой JSON на сервер с GET), он работает как бриз.
Другим преимуществом является то, что вы можете вызывать все разные системы (разработки и тестирования) с одного и того же локального хоста.

Answer 3

Есть разные способы обойти это, в зависимости от того, какой браузер вы используете для разработки.Например:

• В Firefox (Gecko) установите security.fileuri.strict_origin_policy на false
• В Chrome запустите браузер с параметром --allow-file-access-from-files

Ссылки: Firefox , Chrome

Answer 4

Не касаясь сервера -

Самый быстрый и простой способ обойти ту же политику безопасности источника в Firefox - это установить дополнение Force CORS. Это работает с любым сервисом, вставляя соответствующие заголовки в каждый ответ.

https://addons.mozilla.org/en-US/firefox/addon/forcecors/

Answer 5

localhost запрещено использовать в CORS http://code.google.com/p/chromium/issues/detail?id=67743 вместо lvh.me используйте

Answer 6

У меня тоже была такая проблема с использованием Chrome, и опция --allow-file-access-from-files не очень помогла. Возвращаясь к сценарию, который должен был вернуть мой сервер, я добавил эти заголовки в ответ, и он работал нормально:

'Access-Control-Allow-Origin: http://localhost/'

и еще один для разрешения своего рода обмена ключами

'Access-Control-Allow-Headers: X-KEY'

Answer 7

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

Вам необходимо настроить веб-сервер в своей среде разработки (если он еще не установлен), а затем настроить сервер так, чтобы он отвечал на 404 запроса путем выборки, а затем отображал производственные данные. Вы можете настроить свой сервер таким образом, чтобы отбирались только файлы данных AJAX (в противном случае будет затруднительно отлаживать другие файлы, если производственные ресурсы начнут появляться на ваших страницах разработки). Так что если http://dev.myserver.com/data/json/mydata.json отсутствует, ваш скрипт 404 получит http://prod.myserver.com/data/json/mydata.json и отправит его клиенту. Хорошая вещь в этой настройке состоит в том, что вы можете очень легко использовать фиктивные данные: если файл находится в вашей среде разработки, ваш AJAX-скрипт получит это; но если вы затем удалите или переименуете этот файл, вы получите вместо этого производственные данные. Эта функция была настолько полезной, что я не могу рекомендовать ее достаточно.

Если вы работаете с XML, я бы рекомендовал дублировать заголовки HTTP в 404. Если ваш процесс 404 отвечает с Content-Type из text/html, вы не получите responseXML для анализа.

Answer 8

попробуйте это (php curl ayax cross domain - от google ):

http://www.iacons.net/writing/2007/08/02/ajax-cross-domain-proxy/

http://www.phpfour.com/blog/2008/03/cross-domain-ajax-using-php/

http://jquery -howto.blogspot.com / 2009/04 / междоменное-Ajax-выполнение запроса-с-jquery.html