Настройка IIS Express 8 для включения CORS

Я пишу службы WCF, которые будут использоваться клиентами в дикой природе, поэтому им нужно обрабатывать запросы перекрестного происхождения. У меня проблема с включением моего сервера разработки для приема таких запросов. Вот сценарий:

  • Я запускаю проект WCF в экземпляре Visual Studio 2012, используя IIS Express 8 в качестве сервера на определенном порту.
  • Я запускаю клиентский проект в другом экземпляре Visual Studio 2012, также используя IIS Express 8 в качестве сервер. Этот проект использует AJAX для использования служб в другом проекте.

когда я запускаю клиентский проект в IE, нет проблем, потому что IE не отправляет запрос параметров предполетной подготовки. Когда я запускаю его в Chrome, однако запрос параметров предполетной подготовки возвращает метод 405, не разрешенный, и Chrome отказывается от службы. Предыдущие версии Chrome просто проигнорируют ошибку и продолжат фактический запрос POST (или Get, что угодно...) но более поздние версии разборчивее.

Я также столкнулся с этим с развернутым проектом WCF и решил его, переместив OPTIONSVerbHandler в верхнюю часть списка сопоставлений обработчиков в IIS.

Я должен отметить, что я использую самую щедрую сеть.настройки конфигурации, которые я могу придумать, чтобы попытаться разрешить CORS. Например, у меня есть это в конфигурации проекта WCF:

<httpProtocol>
  <customHeaders>
    <remove name="X-Powered-By" />
    <add name="Access-Control-Allow-Origin" value="*" />
    <add name="Access-Control-Allow-Headers" value="*" />
    <add name="Access-Control-Allow-Methods" value="*" />
    <add name="X-Powered-By" value="*" />
  </customHeaders>
</httpProtocol>

независимо от того, все клиентские запросы перекрестного происхождения к проекту WCF, запущенному из кода, завершаются с ошибкой 405 ошибка.

любая помощь в настройке самого проекта WCF или IIS Express 8 для включения CORS?

спасибо!

7
cors cross-domain iis-express visual-studio-2012 wcf

4 ответов

вы можете включить cors для wcf, и это может быть довольно просто, как только вы знаете, как.

разработка Из ответа DavidG на более общий вопрос "cors на IIS", ответ, который действительно близок к тому, что требуется для базового решения:

  • во-первых, настройки OPTIONSVerbHandler для выполнения перед обработчиками .Net.

    1. в консоли IIS выберите "сопоставления обработчиков". (Сделайте это либо на уровне сервера, либо на уровне сайта. На месте уровень он переопределит все обработчики для вашего сайта и проигнорирует любые изменения, сделанные на уровне сервера после этого. И, конечно, на уровне сервера это может сломать другие сайты, если им нужна собственная обработка глагола опций.)
    2. в области действий выберите " Просмотреть список заказов...". Искать OPTIONSVerbHandler, и переместить его вверх (много кликов...).

    вы также можете сделать это в интернете.config путем переопределения всех обработчиков в<system.webServer><handlers>. (<clear> затем <add ...> их обратно, это то, что делает Консоль IIS для вас. Кстати, нет необходимости запрашивать разрешение "read" на этот обработчик.)

  • во-вторых, настройте пользовательские заголовки http для ваших потребностей cors, таких как:

    <system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="Access-Control-Allow-Origin" value="*"/>
      <add name="Access-Control-Allow-Headers" value="Content-Type"/>
      <add name="Access-Control-Allow-Methods" value="POST,GET,OPTIONS"/>
    </customHeaders>
  </httpProtocol>
</system.webServer>

    в этом примере задайте их для всех ответов на все запросы на сайте / приложении / каталоге, в котором находится веб.конфиг. Если вы хотите ограничить их некоторым url-адресом, поместите это в <location> тег.
    Эти пользовательские заголовки также можно добавить в консоль IIS.

это базовое решение, так как он будет отправлять заголовки CORS даже по запросу, который не требует этого, возможно, открытие вашего приложения для неожиданных применений. Но с WCF это выглядит как самый простой.

С MVC или webapi мы могли бы вместо этого обрабатывать OPTIONS заголовки глаголов и cors по коду (либо" вручную", либо со встроенной поддержкой, доступной в последней версии webapi).

13
  • как значение допустимо только для Access-Control-Allow-Origin. Для остальных нужно быть откровенным. Например:

Access-Control-Allow-методы: GET, PUT, POST, DELETE

или же:

Access-Control-Allow-методы: PUT, DELETE

потому что спецификация говорит, что GET и POST подразумеваются.

3

ответ заключается в том, что конфигурация, необходимая для того, чтобы WCF мог принимать сообщения CORS preflight, не имеет ничего общего с сервером IIS; скорее, сам проект WCF должен быть настроен для обработки HTTP-запроса с помощью команды OPTIONS.

короче говоря: делать это очень сложно. WCF-это гнездо всех сделок, когда дело доходит до конечных точек, поэтому настройка его для выполнения чего-то очень конкретного с одним (HTTP) не рекомендуется, хотя это можно сделать. Реальное решение-использовать Web API, который является мастером HTTP и может быть настроен для выполнения CORS очень просто.

1

Я просто хотел упомянуть, что на момент написания этой статьи я не верю, что веб-браузеры поддерживают значение * wildcard для Access-Control-Allow-Methods или Access-Control-Allow-Headers даже если это в спецификации.

Spec:

https://www.w3.org/TR/cors/
https://tools.ietf.org/html/rfc2616#section-4.2

см. примечания по совместимости (проще чтение):

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

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

0