web-dev-qa-db-fra.com

IIS demande des options de contrôle en amont de la CORS

Je fais une demande CORS POST et je définis l'en-tête Content-Type sur json. Cela déclenche une demande de contrôle en amont des OPTIONS de contrôle en amont (ce qui est bon et attendu)

La réponse à cette demande OPTIONS est 200 OK, mais cela ne provient pas de mon application WebAPI. 

J'ai un gestionnaire de messages personnalisé en place et il ne sera jamais touché. Par conséquent, la demande reçoit une réponse de IIS avant d'appuyer sur ASP.NET, semble-t-il.

J'ai trouvé plusieurs articles sur le sujet et ils disent ce qui suit

  1. Assurez-vous que WebDav est désinstallé/supprimé/désactivé - TERMINÉ

  2. Assurez-vous que OPTIONSVerbHandler est supprimé/modifié pour utiliser aspnet_isapi.dll - TRIED BOTH

  3. Assurez-vous que extensionlessURLHandler inclut le verbe OPTIONS - DONE

Cependant, ma demande d'options est toujours en train d'être piratée. J'entends par là que IIS répond avec 200 OK mais n'inclut pas d'en-tête Access-Control-Allow-Origin dans la réponse. Il n'inclut pas cet en-tête car il n'aboutit jamais dans mon code WebAPI CORS qui définirait cet en-tête.

Les deux meilleurs posts que j'ai pu trouver qui sonnent comme mon numéro sont 

ici: JQuery bloqué au contrôle en amont de la CORS et à la réponse IIS fantôme

et ici: http://brockallen.com/2012/10/18/cors-iis-and-webdav/

J'ai essayé d'activer le suivi des demandes ayant échoué (FERB) dans IIS et de le configurer pour suivre tous les 200 codes d'état. Je ne vois jamais la demande d'options en cours de journalisation ... Pas sûr que cela signifie que FERB ne suit pas les demandes OPTIONS ou si je dois modifier quelque chose dans les paramètres de FERB pour le faire suivre les demandes OPTIONS, ou s'il s'agit d'un indice à quel est mon problème? 

ASP.NET WebAPI 2.0 est exécuté sur IIS 7.5 (également testé sur IIS 8 et IISExpress avec les mêmes résultats) Quel que soit le navigateur utilisé (Chrome, FF et IE tous échouent de la même manière) 

J'ai essayé tout ce que je peux trouver sur le sujet et je ne parviens toujours pas à résoudre mon problème.

Aidez-moi StackOverflow, vous êtes mon seul espoir.

asp.net-mvciisasp.net-web-apicors
31
Brad Cunningham

Quelques choses que vous pouvez essayer ici, toutes liées à web.config, modifient d’abord votre élément de modules pour inclure l’attribut runAllManagedModulesForAllRequests="true", comme ci-dessous: 

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

Puis définissez vos gestionnaires sur les éléments suivants: 

<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>

Cela devrait faire l'affaire, mais si ce n'est pas le cas, vous pouvez forcer IIS à générer les en-têtes corrects avec les éléments ci-dessous:

  <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>

Méfiez-vous de la valeur de caractère générique, vous devez vraiment définir cela sur le nom de domaine sur lequel votre site sera hébergé.

24
Tom Hall

c'est ce qui a fonctionné pour moi après 4 heures de recherche/d'expérimentation:

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

J'ai eu le même problème et les paramètres web.config suivants l'ont corrigé.

    <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>

J'ai ensuite pu gérer les demandes CORS OPTIONS manuellement dans Application_BeginRequest.

J'utilisais à l'origine la bibliothèque détaillée dans ce blog post pour le traitement des demandes CORS. Le produit sur lequel je travaille nécessite que runAllManagedModulesForAllRequests soit défini sur false, par contre. C'est pourquoi j'ai dû configurer une implémentation personnalisée, mais si vous n'avez pas cette exigence, vous devriez essayer cette bibliothèque. Cela a bien fonctionné lorsque j'ai réussi à définir runAllManagedModulesForAllRequests sur true.

6
jdehlin

J'ai essayé toutes les suggestions ci-dessus ainsi que d'autres que j'ai trouvées sur SO et ce qui importait dans ma situation était que nous avions le filtrage des demandes activé sur IIS et que le verbe OPTIONS HTTP n'était pas dans la liste des verbes autorisés . Une fois que je l'ai ajouté, j'ai pu régler le reste.

4
powdernine

Dans notre cas, il s’agissait de filtrer les requêtes dans IIS en désactivant le verbe OPTIONS au niveau de l’application Web racine. Ouvrez le gestionnaire IIS, cliquez sur l'application racine, cliquez sur Filtrage des demandes, si OPTIONS apparaît dans la liste, supprimez ou Autorisez les verbes. J'aurais bien voulu vérifier cela en premier car beaucoup de temps perdu.

3
Smithyhammer

Dans mon cas, j'ai raté le paquet Microsoft.WebApi.Cors . J'ai installé ce paquet et je l'ai configuré comme ceci dans la classe 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 }
            );
        }

Veuillez ajuster cela avant d'utiliser dans la production, car vous ne voulez probablement pas avoir de joker pour tout.

1
Nico Timmerman

J'ai installé Microsoft.AspNet.WebApi.Cors & Microsoft.Owin.Cors pour mon WebAPI basé sur oWin et ajouté app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); à la configuration comme ci-dessous:

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

    }
0
Md. Rousonur Jaman

Je sais que ceci est un ancien post, mais je viens de traverser exactement le même problème.

Dans ma situation, CORS est installé pour OWIN et WebAPI. Le middleware OWIN CORS interceptait l'appel OPTIONS bien avant de passer au WebAPI. Peut-être que cela aidera peut-être quelqu'un d'autre à l'avenir.

0
aasukisuki

J'ai essayé tous les articles mentionnés mais rien ne fonctionnait pour moi, puis j'ai transféré mon service ASP.Net Web API 2 sur Windows Server 2012 (IIS 8.5) et le même service fonctionnait sans modification. Le problème était donc spécifique à IIS 7.5 sur Windows 7.

0
Ashish Jain

C'est ce qui a fonctionné pour moi:

  <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>
0
Shiroy