Хостинг статического контента в разных доменах из веб-сервисов, как избежать междоменного?

Недавно мы работали над довольно современным веб-приложением и готовы к его развертыванию для альфа-бета-тестирования и получения опыта в реальном мире.

У нас есть веб-службы на основе ASP.Net(веб-Api) и интерфейс JavaScript, который является 100% -ной MVC-клиентской MVC с использованием магистрали.

Мы приобрели наше доменное имя, и для этого вопроса наше развертывание выглядит следующим образом:

webservices.mydomain.com(Webservices)

mydomain.com(front-end JavaScript)

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

На нашем компьютере разработки мы использовали обратный прокси IIS для пересылки всех запросов на mydomain.com/webservices на webservices.mydomain.com - который решает все наши проблемы, поскольку браузер считает, что все находится в одном домене.

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

Я хочу использовать CloudFront CDN, поскольку все наши серверы/службы размещены на Amazon, я действительно пытаюсь найти информацию, если CDN может поддерживать этот тип установки.

Спасибо

6 ответов

То, что вы пытаетесь сделать, это вызовы между поддоменами, а не полностью междоменные. Вот трюки для этого: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/

Как выясняется, как этот вопрос чаще всего решается. Мой ответ: этот вопрос обычно ИЗБЕГАЕТСЯ. В реальном мире вы должны настроить свои домены, например, вам не нужно делать такие способы, чтобы просто запустить приложение или настроить прокси-сервер для переадресации вызовов для вас. JSONP также является хакерским решением.


Чтобы разрешить эту веб-службу вызываться из script, используя ASP.NET AJAX, добавьте следующую строку в первый код кода веб-службы:

[System.Web.Script.Services.ScriptService]


Если у вас есть пропускная способность (сетевой ввод-вывод и процессор), чтобы справиться с этим, обратный прокси - отличное решение. Хороший обратный прокси-сервер даже кэширует статические вызовы, чтобы уменьшить задержку сети, введенную прокси-сервером.

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


У вас есть 2/3 слоя

в веб-службе класс code-behin, добавьте этот атрибут: <system.web.script.services.scriptservice()> _</system.web.script.services.scriptservice()>

Возможно, вам нужно добавить это в System.web node вашего web.config:

<webservices>
 <protocols>
 <add name="AnyHttpSoap">
 <add name="HttpPost">
 <add name="HttpGet">
 </add></add></add></protocols>
 </webservices>

В клиентском интерфейсе

-Добавить веб-ссылку на услугу на субдомене (exmpl. webservices.mydomain.com/svc.asmx) Visual studio делает "прокси-класс"

-add в коде управления главной страницы страницы | -Просто вызовите эти функции с клиентской стороны

Вы можете использовать функциональность AJAX с помощью scriptmanager или использовать другую систему, такую ​​как JQuery.

Если ваш основной сайт скомпилирован в .NET 3.5 или старше, вам нужно добавить ссылку на пространство имен System.Web.Extensions и объявить его в файле web.config.


Вы можете просто использовать JSONP для запросов AJAX, тогда междоменность не является проблемой.

Если запрос AJAX возвращает некоторый HTML-код, он может быть экранирован в строку JSON.

Во-вторых, это немного неудобно.


easyXDM - это плагин Javascript с перекрестным доменом, который может стоить изучить. Он использует стандарты, когда браузер поддерживает их, и абстрагирует различные хаки, требуемые, когда браузер не поддерживает стандарты. Из easyXDM.net:

easyXDM - это библиотека Javascript, которая позволяет вам как разработчику легко обойти ограничение, установленное на месте одним и тем же происхождением Политика, в свою очередь, упрощает общение и предоставляет javascript API через границы домена.

В ядре easyXDM обеспечивает транспортный стек, способный к передаче строковые сообщения между двумя окнами, потребитель (основной документ) и поставщика (документ, включенный с использованием iframe). Это делает это, используя один из нескольких доступных методов, всегда выбрав наиболее эффективный для текущего браузера. Для всех реализации транспортный стек предлагает двунаправленную, надежности, очереди и проверки отправителя.

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

Чтобы процитировать простого автора XDM:

... сайты, такие как LinkedIn, Twitter и Disqus, а также приложения Nokia и другие создали свои приложения поверх система обмена сообщениями, предоставляемая easyXDM.

Так что easyXDM явно не какой-то poxy-хак, но я признаю его большую зависимость от вашего проекта.

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

См. также этот вопрос SO.

licensed under cc by-sa 3.0 with attribution.