Die Antwort auf die Preflight-Anforderung besteht die Zugriffskontrollprüfung nicht

Ich erhalte diesen Fehler, wenn ngResource zum Aufrufen einer REST-API in Amazon Web Services verwendet wird:

XMLHttpRequest kann http://server.apiurl.com:8000/s/login?login=facebook nicht laden . Die Antwort auf die Preflight-Anforderung besteht die Zugriffssteuerungsprüfung nicht: In der angeforderten Ressource ist kein Header 'Access-Control-Allow-Origin' vorhanden. Origin ' http: // localhost ' ist daher kein Zugriff gestattet. Fehler 405

Bedienung:

socialMarkt.factory('loginService', ['$resource', function($resource){    
    var apiAddress = "http://server.apiurl.com:8000/s/login/";
    return $resource(apiAddress, { login:"facebook", access_token: "@access_token" ,facebook_id: "@facebook_id" }, {
                getUser: {method:'POST'}
            });
}]);

Regler:

[...]
loginService.getUser(JSON.stringify(fbObj)),
                function(data){
                    console.log(data);
                },
                function(result) {
                    console.error('Error', result.status);
                }
[...]

Ich verwende Chrome und weiß nicht, was ich sonst tun soll, um dieses Problem zu beheben. Ich habe den Server sogar so konfiguriert, dass er Header vom Ursprung akzeptiert localhost.

Sie haben Probleme mit CORS.

Es gibt verschiedene Möglichkeiten, dies zu beheben / zu umgehen.

1. Schalten Sie CORS aus. Zum Beispiel: Wie man Cors in Chrom ausschaltet
2. Verwenden Sie ein Plugin für Ihren Browser
3. Verwenden Sie einen Proxy wie Nginx. Beispiel für die Einrichtung
4. Führen Sie die erforderlichen Einstellungen für Ihren Server durch. Dies ist eher ein Faktor des Webservers, den Sie auf Ihre EC2-Instanz geladen haben (vorausgesetzt, Sie meinen dies mit "Amazon-Webdienst"). Informationen zu Ihrem spezifischen Server finden Sie auf der Website zum Aktivieren von CORS.

Ausführlicher ist, dass Sie versuchen, von localhost aus auf api.serverurl.com zuzugreifen. Dies ist die genaue Definition der domänenübergreifenden Anforderung.

Wenn Sie es entweder ausschalten, um Ihre Arbeit zu erledigen (OK, stellen Sie eine schlechte Sicherheit für Sie bereit, wenn Sie andere Websites besuchen und nur die Dose in die Knie zwingen), können Sie einen Proxy verwenden, der Ihren Browser glauben lässt, dass alle Anfragen vom lokalen Host kommen, wenn Sie haben wirklich einen lokalen Server, der dann den Remote-Server aufruft.

Daher wird api.serverurl.com möglicherweise zu localhost: 8000 / api und Ihr lokaler Nginx oder ein anderer Proxy wird an das richtige Ziel gesendet.

Jetzt auf vielfachen Wunsch 100% mehr CORS-Infos .... gleicher toller Geschmack!

Und für die Downvoter ... die Umgehung von CORS ist genau das, was für diejenigen gezeigt wird, die einfach das Frontend lernen. https://codecraft.tv/courses/angular/http/http-with-promises/

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

Platzieren Sie 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 der AspNetCore-Web-API wurde dieses Problem behoben, indem "Microsoft.AspNetCore.Cors" (Version 1.1.1) hinzugefügt und die folgenden Änderungen in Startup.cs hinzugefügt wurden.

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 setzen [EnableCors("AllowAllHeaders")] des Controllers.

Es gibt einige Einschränkungen, wenn es um CORS geht. Erstens erlaubt es keine Platzhalter, *aber halte mich nicht an diesem fest. Ich habe ihn irgendwo gelesen und kann den Artikel jetzt nicht finden.

Wenn Sie Anforderungen von einer anderen Domäne stellen, müssen Sie die zulässigen Ursprungsheader 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 dem folgenden application/x-www-form-urlencodedunterscheidet multipart/form-data, oder text/plainder Browser automatisch eine OPTIONS-Anforderung vor dem Flug sendet, um beim Server zu prüfen, ob dies zulässig ist .

Ihre API / Ihr Server muss diese OPTIONS-Anforderungen entsprechend behandeln. Sie müssen mit dem entsprechenden access control headersund dem http-Antwortstatuscode antworten 200.

Die Überschriften sollten ungefähr 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

Der Max-Age-Header ist wichtig, in meinem Fall würde er ohne ihn nicht funktionieren. Ich denke, der Browser benötigt die Informationen darüber, wie lange die "Zugriffsrechte" gültig sind.

Wenn Sie z. B. eine POSTAnfrage mit application/jsonMIME aus einer anderen Domain stellen, müssen Sie außerdem den zuvor erwähnten Header zum Zulassen des Ursprungs hinzufügen, damit dies folgendermaßen 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 Vorflug erfolgreich ist und alle erforderlichen Informationen erhält, wird Ihre eigentliche Anfrage gestellt.

Im Allgemeinen Access-Controlsollte in der Antwort angegeben werden , welche Header in der Erst- oder Vorfluganforderung angefordert werden, damit sie funktionieren.

Es gibt ein gutes Beispiel in den MDN-Dokumenten hier unter diesem Link , und Sie sollten auch diesen SO-Beitrag lesen

JavaScript XMLHttpRequest und Fetch folgen der Richtlinie mit demselben Ursprung. Eine Webanwendung, die XMLHttpRequest oder Fetch verwendet, konnte daher nur HTTP-Anforderungen an ihre eigene Domäne senden.

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 es wie folgt zu Ihrer Apache-Konfigurationsdatei hinzufügen:

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

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

 a2enmod headers

Wenn Sie eine Chrome-Erweiterung schreiben

Sie müssen manifest.jsondie Berechtigungen für Ihre Domain (s) hinzufügen .

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

Wenn Sie zufällig einen IIS-Server verwenden. Sie können die folgenden Header in der Option HTTP-Anforderungsheader 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 alle Post, bekommen usw., wird gut funktionieren.

Für Python Flask Server können Sie das Flask-Cors-Plugin verwenden, um domänenübergreifende Anforderungen zu aktivieren.

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

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: *");
...

So beheben Sie Probleme zwischen Ursprungsanforderungen in einer Node JS-Anwendung:

npm i cors

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

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 diejenigen, die Lambda Integrated Proxy mit API-Gateway verwenden . Sie müssen Ihre Lambda-Funktion so konfigurieren, als würden Sie Ihre Anforderungen direkt an sie senden. Dies bedeutet, dass die Funktion die Antwortheader ordnungsgemäß einrichten sollte. (Wenn Sie benutzerdefinierte Lambda-Funktionen verwenden, wird dies vom API-Gateway übernommen.)

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

Ich denke, das Deaktivieren von CORS aus Chrome ist kein guter Weg , denn wenn Sie es in ionic verwenden, wird das Problem in Mobile Build sicherlich erneut auftreten.

Also besser in deinem Backend reparieren.

Zunächst müssen Sie im Header Folgendes festlegen:

• Header ('Access-Control-Allow-Origin: *');
• Header ('Header-Set Access-Control-Allow-Header: "Origin, X-Requested-With, Inhaltstyp, Accept"');

Und wenn sich die API wie GET und POST verhält, dann setzen Sie auch 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']}"); Ausfahrt (0); }}

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 einem C # WebApi. Durch Hinzufügen eines Routenattributs zu dem Endpunkt, den Sie treffen möchten, wird dies für uns behoben.

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

Ich habe 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 versuchte, über Google eine Verbindung zum Server herzustellen, nicht lokal (für meinen speziellen Fall). Ich habe 8.8.8.8 entfernt und dies hat 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 habe, bin ich auf diesen Thread gestoßen. Dank @lsimoneau 45581857 stellte sich heraus, dass genau das Gleiche geschah. Ich habe meine Anforderungs-URL einfach auf die Region in meinem Bucket gerichtet, indem ich die Regionsoption angehängt habe, und es hat funktioniert.

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

Zu den eigenständigen Distributionen von GeoServer gehört der Jetty-Anwendungsserver. Aktivieren Sie CORS (Cross-Origin Resource Sharing), damit JavaScript-Anwendungen außerhalb Ihrer eigenen Domäne GeoServer verwenden können.

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

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

Es ist einfach, dieses Problem mit wenigen Schritten zu lösen, ohne sich um irgendetwas kümmern zu müssen. Bitte folgen Sie den Schritten, um es zu lösen.

1. offen ( https://www.npmjs.com/package/cors#enabling-cors-pre-flight )
2. Gehen Sie zur Installation und kopieren Sie den Befehl npm install cors, um ihn über das Knotenterminal zu installieren
3. Gehen Sie zu Einfache Verwendung (Alle CORS-Anforderungen aktivieren), indem Sie scrollen. Kopieren Sie dann die vollständige Deklaration und fügen Sie sie in Ihr Projekt ein. Führen Sie sie aus. Dies funktioniert auf jeden Fall. Kopieren Sie den Kommentarcode und fügen Sie sie in Ihre app.js oder eine andere ein Projektieren und probieren Sie es aus. Dies wird funktionieren. Dadurch wird jede gemeinsame Nutzung von Ressourcen zwischen verschiedenen Freischaltungen freigeschaltet. So können wir zwischen Aufschlägen für Ihre Verwendung wechseln

Etwas, das sehr leicht zu übersehen ist ...

Klicken Sie im Solution Explorer mit der rechten Maustaste auf das API-Projekt. Setzen Sie im Eigenschaftenfenster 'Anonyme Authentifizierung' auf Aktiviert !!!

Deaktivieren Sie die Chrome-Sicherheit. Erstellen Sie eine Chrome-Verknüpfung mit der rechten Maustaste -> Eigenschaften -> Ziel und fügen Sie dieses "C: \ Programme (x86) \ Google \ Chrome \ Application \ chrome.exe" --disable-web-security --user ein -data-dir = "c: / chromedev"