it-swarm.com.de

IIS Hijacks CORS Preflight OPTIONS Anfrage

Ich mache eine CORS POST -Anforderung und setze den Content-Type-Header auf json. Dadurch wird eine Preflight-OPTIONS-Anforderung ausgelöst, die ausgelöst werden soll (dies ist gut und wird erwartet).

Diese OPTIONS-Anfrage wird mit 200 OK beantwortet, aber sie stammt nicht aus meiner WebAPI-Anwendung. 

Ich habe einen benutzerdefinierten Message-Handler, der nie getroffen wird. Daher wird auf die Anforderung von IIS = geantwortet, bevor ASP.NET aufgerufen wird.

Ich habe mehrere Beiträge zu diesem Thema gefunden und sie sagen folgendes

  1. Stellen Sie sicher, dass WebDav deinstalliert/entfernt/deaktiviert wurde - DONE

  2. Stellen Sie sicher, dass der OPTIONSVerbHandler entfernt/geändert wurde, um aspnet_isapi.dll - TRIED BOTH zu verwenden.

  3. Stellen Sie sicher, dass der extensionlessURLHandler das Verb "OPTIONS" enthält - DONE.

Allerdings wird meine Optionsanfrage immer noch gekapert. Damit meine ich: IIS antwortet mit bei 200 OK, ohne jedoch einen Access-Control-Allow-Origin-Header in die Antwort aufzunehmen. Dieser Header ist nicht enthalten, da er niemals zu meinem WebAPI-CORS-Code gelangt, der diesen Header setzen würde.

Die zwei besten Beiträge, die ich finden konnte, klingen wie meine Ausgabe 

hier: JQuery bleibt bei CORS Preflight und IIS Geisterantwort

und hier: http://brockallen.com/2012/10/18/cors-iis-and-webdav/

Ich habe versucht, Failed Request Tracing (FERB) in IIS zu aktivieren, und es so einzustellen, dass alle 200 Statuscodes verfolgt werden. Ich sehe nicht, dass die Optionsanforderung protokolliert wird. Nicht sicher, ob FERB OPTIONS-Anforderungen nicht verfolgt oder ob ich etwas in den FERB-Einstellungen ändern muss, um OPTIONS-Anforderungen zu verfolgen, oder ob dies ein Hinweis ist zu was ist mein problem 

Dies ist ASP.NET WebAPI 2.0, das auf IIS 7.5 ausgeführt wird (wurde auch auf IIS 8 und IISExpress mit den gleichen Ergebnissen getestet.) IE alle scheitern auf die gleiche Weise) 

Ich habe alles versucht, was ich zu diesem Thema finden kann, und kann mein Problem immer noch nicht lösen.

Helfen Sie mir, StackOverflow, Sie sind meine einzige Hoffnung.

31
Brad Cunningham

Ein paar Dinge, die Sie hier, alles in Bezug auf web.config, versuchen können, ändern Sie zunächst Ihr modules-Element, um das Attribut runAllManagedModulesForAllRequests="true" wie folgt aufzunehmen: 

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

Stellen Sie dann Ihre Handler auf das Folgende ein: 

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

Dies sollte den Trick tun, aber wenn nicht, können Sie als letzten Ausweg IIS zwingen, die korrekten Header mit den folgenden Informationen auszugeben:

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

Seien Sie vorsichtig mit dem Platzhalterwert. Sie sollten dies wirklich auf den Domainnamen setzen, auf dem Ihre Site gehostet wird.

24
Tom Hall

das hat bei mir nach 4 stunden des suchens/experimentierens funktioniert:

    <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

Ich hatte das gleiche Problem und die folgenden web.config-Einstellungen haben es für mich behoben.

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

Ich konnte dann CORS OPTIONS-Anforderungen manuell in Application_BeginRequest bearbeiten.

Ursprünglich habe ich die in diesem Blog-Beitrag beschriebene Bibliothek zur Bearbeitung von CORS-Anfragen verwendet. Das Produkt, an dem ich gerade arbeite, setzt voraus, dass runAllManagedModulesForAllRequests auf false gesetzt ist. Aus diesem Grund musste ich eine benutzerdefinierte Implementierung einrichten, aber wenn Sie diese Anforderung nicht haben, sollten Sie es mit der Bibliothek versuchen. Es hat super funktioniert, als ich runAllManagedModulesForAllRequests auf true setzen konnte.

6
jdehlin

Ich habe alle oben genannten Vorschläge ausprobiert und auch andere, die ich unter SO gefunden habe. Was in meiner Situation von Belang war, war, dass Request Filtering für IIS aktiviert war und das HTTP-Verb von OPTIONS nicht in der Liste der zulässigen Verben war . Nachdem ich es hinzugefügt hatte, konnte ich den Rest in Ordnung bringen.

4
powdernine

In unserem Fall handelte es sich um eine Anforderungsfilterung in IIS, wodurch das Verb OPTIONS auf der Ebene der Stammwebanwendung deaktiviert wurde. Öffnen Sie den IIS - Manager, klicken Sie auf Root-Anwendung, klicken Sie auf Request Filtering, wenn OPTIONS in der Liste entweder remove oder Allow Verb angezeigt wird. Ich wünschte, ich hätte dies als viel verschwendete Zeit überprüft.

3
Smithyhammer

In meinem Fall habe ich das Microsoft.WebApi.Cors-Paket vermisst . Dieses Paket wurde installiert und wie in der WebApiConfig-Klasse konfiguriert:

 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 }
            );
        }

Bitte stellen Sie dies vor dem Einsatz in der Produktion ein, da Sie wahrscheinlich keine Platzhalter für alles haben möchten

1
Nico Timmerman

Ich habe Microsoft.AspNet.WebApi.Cors & Microsoft.Owin.Cors für meine eigene webAPI installiert und app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); bei config wie folgt hinzugefügt:

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

Ich weiß, das ist ein alter Beitrag, aber ich habe genau das gleiche Problem durchgemacht.

In meiner Situation habe ich CORS sowohl für OWIN als auch für WebAPI installiert. Die Middleware von OWIN CORS hat den Aufruf von OPTIONS bereits vor der Veröffentlichung von WebAPI unterbrochen. Vielleicht hilft das auch jemandem in der Zukunft.

0
aasukisuki

In meinem Fall habe ich das gemacht:

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

Wenn ich <add verb="OPTIONS" allowed="true"/> Zur web.config hinzufügte, konnte die Anwendung mit diesem Fehler nicht gestartet werden

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'

Also musste ich es zuerst entfernen.

0
Mahmoodvcs

Ich habe alle erwähnten Beiträge ausprobiert, aber nichts hat für mich funktioniert, dann habe ich meinen ASP.Net Web API 2-Dienst auf Windows Server 2012 (IIS 8.5) verlagert und derselbe Dienst funktionierte ohne Änderungen. Das Problem war also spezifisch für IIS 7.5 unter Windows 7.

0
Ashish Jain

Das hat bei mir funktioniert:

  <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