Подтвердить что ты не робот

IIS захватывает запрос CORS Preflight OPTIONS

Я делаю запрос CORS POST и устанавливаю заголовок Content-Type в json. Это вызывает запрос Preflight OPTIONS для срабатывания (это хорошо и ожидаемо)

На этот запрос OPTIONS ответят с помощью 200 OK, но это не происходит из моего приложения WebAPI.

У меня есть специальный обработчик сообщений на месте, и он никогда не попадает, так что запрос получает IIS перед тем, как поразить ASP.NET.

Я нашел несколько сообщений по этому вопросу, и они говорят следующее

  • Убедитесь, что WebDav удален/удален/отключен - СОВЕРШЕННО

  • Убедитесь, что OPTIONSVerbHandler удален/изменен для использования aspnet_isapi.dll - TRIED BOTH

  • Убедитесь, что extensionlessURLHandler содержит глагол OPTIONS - DONE

Однако мой запрос параметров по-прежнему увозят. Под этим я подразумеваю, что IIS отвечает на 200 OK, но не включает заголовок Access-Control-Allow-Origin в ответе. Он не включает этот заголовок, потому что он никогда не попадает в мой код WebAPI CORS, который бы установил этот заголовок.

Два лучших сообщения, которые я мог найти, похожи на мою проблему:

здесь: JQuery застрял в преддверии CORS и ответе призрака IIS

и здесь: http://brockallen.com/2012/10/18/cors-iis-and-webdav/

Я попытался включить отслеживание Failed Request (FERB) в IIS и настроить его на отслеживание всех 200 кодов состояния. Я никогда не вижу, чтобы запрос параметров регистрировался... Не уверен, что это означает, что FERB не отслеживает запросы OPTIONS или мне нужно что-то изменить в настройках FERB, чтобы отслеживать запросы OPTIONS, или если это ключ к чему моя проблема?

Это ASP.NET WebAPI 2.0, работающий на IIS 7.5 (также проверен на IIS 8 и IISExpress с одинаковыми результатами) Неважно, какой браузер (Chrome, FF и IE не работают одинаково)

Я пробовал все, что мог найти по этому вопросу, но по-прежнему не могу исправить свою проблему.

Помогите мне StackOverflow, вы - моя единственная надежда.

4b9b3361

ОТВЕТЫ

Ответ 1

Несколько вещей, которые вы можете попробовать здесь, все связанные с web.config, сначала измените свой модуль, чтобы включить атрибут runAllManagedModulesForAllRequests="true", как показано ниже:

<modules runAllManagedModulesForAllRequests="true">
    <remove name="WebDavModule" />
</modules>

Затем установите обработчики следующим образом:

<handlers>
   <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" />
   <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
   <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
   <remove name="WebDav" />
   <remove name="OPTIONSVerbHandler" />
   <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" />
   <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" />
   <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>

Это должно сделать трюк, но если это не так, в качестве последнего средства вы можете заставить IIS выводить правильные заголовки ниже:

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

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

Ответ 2

что сработало для меня после 4 часов поиска/экспериментирования:

    <handlers>
        <remove name="OPTIONSVerbHandler" />
        <add name="OPTIONSVerbHandler" path="*" verb="OPTIONS" modules="IsapiModule" scriptProcessor="C:\Windows\System32\inetsrv\asp.dll" resourceType="Unspecified" requireAccess="None" />
    </handlers>

Ответ 3

У меня была такая же проблема, и следующие настройки web.config исправили ее для меня.

    <modules runAllManagedModulesForAllRequests="false">
      <remove name="FormsAuthenticationModule" />
    </modules>
    <handlers>
      <remove name="OPTIONSVerbHandler" />
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>

Затем я смог обрабатывать запросы CORS OPTIONS вручную в Application_BeginRequest.

Я изначально использовал библиотеку, подробно описанную в этом сообщении в блоге для обработки запросов CORS. Продукт, над которым я работаю, требует, чтобы runAllManagedModulesForAllRequests был установлен на false. Вот почему мне пришлось настраивать пользовательскую реализацию, но если у вас нет этого требования, вы должны попробовать эту библиотеку. Он отлично поработал, когда мне удалось установить runAllManagedModulesForAllRequests в true.

Ответ 4

Я пробовал все вышеперечисленные предложения, а также другие, которые я нашел в SO, и что имело значение в моей ситуации: мы включили фильтрацию запросов в IIS, а OPTIONS HTTP-глагол не был в списке допустимых глаголов. Как только я добавил его, я смог разобраться с остальной частью.

Ответ 5

В нашем случае это была фильтрация запросов в IIS, отключая глагол OPTIONS на уровне корневого веб-приложения. Откройте Диспетчер IIS, нажмите на корневое приложение, нажмите "Фильтрация запросов", если в списке "ОПЦИИ" появляется либо "Удалить", либо "Разрешить глагол". Хотелось бы, чтобы я сначала проверил это, так как потратил много времени.

Ответ 6

В моем случае я пропустил пакет Microsoft.WebApi.Cors. Установил этот пакет и настроил его так же в классе WebApiConfig:

 public static void Register(HttpConfiguration config)
        {
            config.MapHttpAttributeRoutes();
            config.EnableCors(new EnableCorsAttribute("*","*","*"));
            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
        }

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

Ответ 7

Проверьте, установлен ли инструмент URLScan на IIS. Когда это так, проверьте следующий раздел:


;
; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
;
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.
;

GET
HEAD
POST
OPTIONS

Ответ 8

Я знаю, что это старый пост, но я просто рассмотрел ту же проблему.

В моей ситуации у меня есть CORS для OWIN и WebAPI. Среднее ПО OWIN CORS перехватывало вызов OPTIONS задолго до того, как оно когда-либо попадало в материал WebAPI. Возможно, это поможет кому-то еще в будущем.

Ответ 9

Я установил Microsoft.AspNet.WebApi.Cors и Microsoft.Owin.Cors для своего WebAPI на основе wwin и добавил app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); в config, как показано ниже:

public class Startup : IStartup, IAppStartup
{
    public void Configuration(IAppBuilder app)
    {
        var config = this.GetInjectionConfiguration();
        BootstrapperWebApi bootstrapperWebApi = (BootstrapperWebApi)this.GetBootstrapperWebApi(config);

        bootstrapperWebApi.Initialize(true)
        .EnableLogging()
        .DisableWebApiDefaultExceptionHandler();

        WebApiConfig.Register(config);

        app.UseOwinExceptionHandler();

        app.Use<LoggerMiddleware>();

        app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll);
        //others stuff

    }

Ответ 10

Я пробовал все упомянутые сообщения, но ничего не работало для меня, затем я переместил свою службу ASP.Net Web API 2 на сервер Windows 2012 (IIS 8.5) и тот же сервис работал без каких-либо изменений. Таким образом, проблема была специфичной для IIS 7.5 на машине Windows 7.

Ответ 11

Вот что сработало для меня:

  <system.webServer>
    <handlers>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
      <remove name="OPTIONSVerbHandler" />
      <remove name="TRACEVerbHandler" />
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
    </handlers>
  </system.webServer>

Ответ 12

В моем случае я сделал это:

    <verbs allowUnlisted="true" applyToWebDAV="true">
      <remove verb="OPTIONS"/>
      <add verb="OPTIONS" allowed="true"/>
    </verbs>
  </requestFiltering>
</security>

Когда я добавил <add verb="OPTIONS" allowed="true"/> в файл web.config, приложение не запустилось с этой ошибкой

HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

Cannot add duplicate collection entry of type 'add' with unique key attribute 'verb' set to 'OPTIONS'

Поэтому мне пришлось сначала удалить его.