JavaScript и CouchDB - Как избежать ошибок политики кросс-происхождения при запросах GET / POST / PUT / DELETE - PullRequest
1 голос
/ 07 сентября 2010

Я также задаю этот вопрос на Super User.На мой взгляд, этот вопрос перекрывает два ... Я создаю простую оболочку JavaScript для REST-ful интерфейса CouchDB, но я застрял в вопросах политики того же происхождения.

До сих пор я разрабатывал свой код для локальной работы -и только в качестве доказательства концепции - на Mozilla FireFox.Мой сервер работает на локальном хосте, порт 5984.

Чтобы отключить политику кросс-происхождения в Mozilla FireFox, вы можете использовать PrivilegeManager , но это дает мне только половину в том смысле, что яне может выполнять PUT-запросы к моему серверу ...

/*
 * Including this in my JavaScript file only seems to disable cross-origin
 * policy checks for POST and GET requests in Mozilla FireFox.
 * PUT requests fail.
 */

netscape.security.PrivilegeManager.enablePrivilege(
    "UniversalBrowserRead UniversalBrowserWrite"
);

Можно ли как-то настроить свой сервер, чтобы скрыть его местоположение, чтобы мне не пришлось реализовывать обходные пути для конкретного браузера, чтобы избежать проблем с политикой того же происхождения?Если нет: какие обходные пути в браузере существуют для полного отключения политики одного и того же происхождения?

Ответы [ 2 ]

3 голосов
/ 07 сентября 2010

К сожалению, любые обходные пути браузера для отключения политик одного и того же происхождения, скорее всего, будут рассматриваться как серьезные ошибки безопасности и исправлены как можно скорее.

Посмотрите, можете ли вы найти способ работать в том же самом-оригинальная политика без попыток ее обойти.

Можете ли вы предоставить примеры сценариев на целевом сервере?Не могли бы вы создать сценарий отражения, который бы загружал целевой сценарий на ваш сервер после того, как локальный сценарий на компьютере пользователя загружал все, что они изменили?

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

0 голосов
/ 06 января 2012

Я тоже боролся с этой проблемой, пытаясь запустить автоматические тесты для локального html-файла, подключенного к виртуализированному серверу CouchDB, вот мое решение:

Я создал небольшую реализацию (и открыл ее),самое простое решение, когда вы не можете включить CORS на сервере,

, вам нужно загрузить файл .js и .html на целевой сервер (вы можете использовать любой механизм безопасности, чтобы ограничить доступ к этому файлу, еслиты хочешь).Или вы можете изменить некоторые простые параметры в html-файле, чтобы они ограничивались доменом.

На своей странице вы используете тот же скрипт, чтобы создать невидимый iframe, в который загружен размещенный .html, и проксировать определенные методы (RPC) через этот iframe с помощью window.postMessage (), по умолчанию jjuery ajax-методы могут быть проксированы без дополнительной настройки.

Все это с одной строкой кода js:)

FrameProxy на GitHub

(не стесняйтесь использовать его и раскошелиться!)

...