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

Question

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


Я создаю простую оболочку 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"
);

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

Answer 1

Политика одинакового происхождения (СОП) была разработана для предотвращения внедрения информации из одного контекста / домена в другой. Они реализованы и применяются браузером. Каждый поставщик может иметь свои собственные СОП. Таким образом, любой обходной путь может работать для одного браузера, в то время как для другого он не будет работать.

ИМХО самое лучшее (и только?) вариант заключается в использовании какого-то прокси.

Если вы используете Apache для размещения вашего веб-приложения, вы можете легко настроить обратный прокси-сервер. Я принимаю запросы и отправляю их в реальный сервис (REST-API). Ответ будет отправлен обратно в браузер. SOP не будет применяться, поскольку конечная точка REST-API будет находиться не в другом домене (то есть на другом сервере), а в домене вашего веб-приложения (благодаря прокси).

[править] Вот лучшее объяснение: http://developer.yahoo.com/javascript/howto-proxy.html