Die Antwort auf die Preflight-Anforderung ist keine Zugriffskontrollprüfung

Mein "API-Server" ist eine PHP -Anwendung. Um dieses Problem zu lösen, habe ich die folgende Lösung gefunden:

Platziere die Zeilen in index.php

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS');
header('Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token');

In AspNetCore Web API wurde dieses Problem durch Hinzufügen von "Microsoft.AspNetCore.Cors" (Version 1.1.1) und Hinzufügen der folgenden Änderungen in Startup.cs behoben.

public void ConfigureServices(IServiceCollection services)
{ 
    services.AddCors(options =>
    {
          options.AddPolicy("AllowAllHeaders",
                builder =>
            {
                    builder.AllowAnyOrigin()
                           .AllowAnyHeader()
                           .AllowAnyMethod();
                });
    });
    .
    .
    .
}

und 

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{


    // Shows UseCors with named policy.
    app.UseCors("AllowAllHeaders");
    .
    .
    .
}

und [EnableCors("AllowAllHeaders")] auf die Steuerung setzen.

JavaScript XMLHttpRequest und Fetch folgen der Same-Origin-Richtlinie. So, Eine Webanwendung, die XMLHttpRequest oder Fetch verwendet, kann nur HTTP .__ erstellen. Anfragen an eine eigene Domain.

Quelle: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Sie müssen den HTTP-Header Access-Control-Allow-Origin: * von Ihrer Serverseite aus senden.

Wenn Sie Apache als HTTP-Server verwenden, können Sie ihn wie folgt zu Ihrer Apache-Konfigurationsdatei hinzufügen:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
</IfModule>

Mod_headers ist standardmäßig in Apache aktiviert. Sie können jedoch sicherstellen, dass sie aktiviert wird, indem Sie Folgendes ausführen:

 a2enmod headers

Wenn Sie eine Chrome-Erweiterung schreiben

Sie müssen im manifest.json die Berechtigungen für Ihre Domäne (n) hinzufügen.

"permissions": [
   "http://example.com/*",
   "https://example.com/*"
]

Wenn Sie den IIS Server zufällig verwenden. Sie können unten in der Option HTTP-Anfragekopfzeilen Header festlegen.

Access-Control-Allow-Origin:*
Access-Control-Allow-Methods: 'HEAD, GET, POST, PUT, PATCH, DELETE'
Access-Control-Allow-Headers: 'Origin, Content-Type, X-Auth-Token';

mit diesem alles post, get etc. wird gut funktionieren.

Bei CORS gibt es einige Vorbehalte. Erstens erlaubt es keine Wildcards *, aber halte mich nicht an diesem. Ich habe ihn irgendwo gelesen und kann den Artikel jetzt nicht finden.

Wenn Sie Anforderungen von einer anderen Domäne aus vornehmen, müssen Sie die zulässigen Origin-Header hinzufügen. Access-Control-Allow-Origin: www.other.com

Wenn Sie Anforderungen stellen, die sich auf Serverressourcen wie POST/PUT/PATCH auswirken, und wenn sich der Mime-Typ von den folgenden Codes application/x-www-form-urlencoded, multipart/form-data oder text/plain unterscheidet, sendet der Browser automatisch eine Anfrage vor dem Flug von OPTIONS an den Server würde es erlauben.

Damit Ihr API/Server diese OPTIONS-Anforderungen entsprechend behandeln muss, müssen Sie mit dem entsprechenden access control headers antworten, und der http-Antwortstatuscode muss 200 sein.

Die Kopfzeilen sollten in etwa so sein, passen Sie sie an Ihre Bedürfnisse an: Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400 Die max-age-Kopfzeile ist wichtig. In meinem Fall würde es ohne sie nicht funktionieren. Ich denke, der Browser benötigt die Informationen dazu solange die "Zugriffsrechte" gültig sind.

Wenn Sie z. Bei einer POST-Anforderung mit application/json-Mime aus einer anderen Domäne müssen Sie auch den zuvor genannten Origin-Header mit Erlaubnis hinzufügen, damit er wie folgt aussieht:

Access-Control-Allow-Origin: www.other.com Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS Access-Control-Allow-Headers: Content-Type Access-Control-Max-Age: 86400

Wenn der Pre-Flight erfolgreich ist und alle erforderlichen Informationen erhalten, wird Ihre aktuelle Anfrage gestellt. 

Im Allgemeinen sollten die Access-Control-Header, die in der Erst- oder Fluganfrage angefordert werden, in der Antwort angegeben werden, damit sie funktioniert.

Es gibt ein gutes Beispiel in den MDN-Dokumenten hier zu diesem Link , und Sie sollten auch dieses SO post auschecken.

In PHP können Sie die Header hinzufügen:

<?php
header ("Access-Control-Allow-Origin: *");
header ("Access-Control-Expose-Headers: Content-Length, X-JSON");
header ("Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS");
header ("Access-Control-Allow-Headers: *");
...

Bei einem Python-Flask-Server können Sie das flask-cors-Plugin verwenden, um domänenübergreifende Anforderungen zu aktivieren.

Siehe: https://flask-cors.readthedocs.io/de/latest/

So beheben Sie Cross-Origin-Anfragen in einer Node-JS-Anwendung:

npm i cors

Und fügen Sie einfach die folgenden Zeilen zum app.js hinzu.

let cors = require('cors')
app.use(cors())

In meiner Apache VirtualHost-Konfigurationsdatei habe ich folgende Zeilen hinzugefügt:

Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, Origin, authorization, accept, client-security-token"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

Für diese verwenden SieLambda Integrated Proxy mit API Gateway. Sie müssen Ihre Lambda-Funktion so konfigurieren, dass Sie Ihre Anforderungen direkt an sie senden, dh die Funktion sollte die Antwort-Header richtig einrichten. (Wenn Sie benutzerdefinierte Lambda-Funktionen verwenden, wird dies vom API-Gateway verarbeitet.) 

//In your lambda's index.handler():
exports.handler = (event, context, callback) => {
     //on success:
     callback(null, {
           statusCode: 200,
           headers: {
                "Access-Control-Allow-Origin" : "*"
           }
     }
}

Ich bin mit diesem Problem konfrontiert, als der DNS-Server auf 8.8.8.8 (google's) eingestellt war. Eigentlich war das Problem im Router, meine Anwendung hat versucht, sich über den Google Server mit dem Server zu verbinden, nicht lokal (für meinen speziellen Fall). Ich habe 8.8.8.8 entfernt und damit das Problem gelöst ... Ich weiß, dass dieses Problem durch die CORS-Einstellungen behoben wurde, aber vielleicht hat jemand die gleichen Probleme wie ich

Ich verwende AWS SDK für Uploads. Nachdem ich einige Zeit online gesucht hatte, bin ich über diesen Thread gestolpert. dank @lsimoneau 45581857 es stellt sich heraus, dass genau das gleiche passiert ist. Ich habe einfach meine Anfrage-URL auf die Region in meinem Bucket gezeigt, indem ich die Regionsoption angehängt habe.

 const s3 = new AWS.S3({
 accessKeyId: config.awsAccessKeyID,
 secretAccessKey: config.awsSecretAccessKey,
 region: 'eu-west-2'  // add region here });

Die Standalone-Distributionen von GeoServer enthalten den Jetty-Anwendungsserver. Aktivieren Sie Cross-Origin Resource Sharing (CORS) , Um JavaScript-Anwendungen außerhalb Ihrer eigenen Domäne die Verwendung von GeoServer zu ermöglichen.

Kommentieren Sie den folgenden <filter> und <filter-mapping> aus webapps/geoserver/WEB-INF/web.xml:

<web-app>
  <filter>
      <filter-name>cross-Origin</filter-name>
      <filter-class>org.Eclipse.jetty.servlets.CrossOriginFilter</filter-class>
  </filter>
  <filter-mapping>
      <filter-name>cross-Origin</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
</web-app>

Eine sehr häufige Ursache für diesen Fehler könnte sein, dass die Host-API die Anforderung einer http-Methode (z. B. PUT) zugeordnet hat und der API-Client die API mit einer anderen http-Methode (z. B. POST oder GET) aufruft

Unser Team sieht dies gelegentlich mit Vue, Axios und einer C # Web Api. Das Hinzufügen eines Routenattributs zu dem Endpunkt, den Sie zu treffen versuchen, behebt es für uns.

[Route("ControllerName/Endpoint")]
[HttpOptions, HttpPost]
public IHttpActionResult Endpoint() { }

Ich denke, das Deaktivieren von CORS von Chrome ist kein guter Weg , denn wenn Sie es in ionischer Form verwenden, wird sich das Problem sicherlich in Mobile Build erneut aufwerfen.

Also besser in Ihrem Backend zu beheben.

Zuallererst müssen Sie in der Kopfzeile

• header ('Access-Control-Allow-Origin: *');
• header ('Header set Access-Control-Allow-Header: "Origin, X-Requested-With, Inhaltstyp, Akzeptieren"');

Und wenn sich API als GET und POST verhält, dann setzen Sie auch Set in Ihrem Header-

if ($ _SERVER ['REQUEST_METHOD'] == 'OPTIONS') {if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_METHOD'])).). header ("Access-Control-Allow-Methoden: GET, POST, OPTIONS");
if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']))) header ("Access-Control-Allow-Header):
{$ _SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']} "); exit (0);}