it-swarm.com.de

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

Ich erhalte diese Fehlermeldung, wenn Sie mit ngResource eine REST - API in Amazon Web Services aufrufen:

XMLHttpRequest kann nicht geladen werden http://server.apiurl.com:8000/s/login?login=facebook . Antwort an Die Preflight-Anforderung besteht keine Zugriffskontrollprüfung: Nein Der Header 'Access-Control-Allow-Origin' ist in der angeforderten .__ vorhanden. Ressource. Origin ' http: // localhost ' hat daher keinen Zugriff . 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 Sie sonst tun müssen, um dieses Problem zu beheben. Ich habe den Server sogar so konfiguriert, dass er Header von Origin localhost akzeptiert.

295
Andre Mendes

Sie stoßen auf CORS-Probleme.

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

  1. CORS ausschalten. Zum Beispiel: wie man cors in chrome ausschaltet
  2. Benutze ein Plugin für deinen Browser
  3. Verwenden Sie einen Proxy wie Nginx. Beispiel für die Einrichtung

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

Wenn Sie diese Option entweder ausschalten, um Ihre Arbeit zu erledigen (OK, wenn Sie andere Websites besuchen und nur die Dose runterwerfen), können Sie einen Proxy verwenden, der Ihren Browser veranlasst, zu denken, dass alle Anforderungen vom lokalen Host kommen, wenn wirklich hast du lokalen server der dann den remote server anruft.

aus api.serverurl.com kann daher localhost werden: 8000/api und Ihr lokaler Nginx- oder anderer Proxy sendet an das richtige Ziel.


Jetzt auf vielfachen Wunsch 100% mehr CORS-Info .... der gleiche gute Geschmack!


Und für die Abwähler ... CORS zu umgehen ist genau das, was für diejenigen gezeigt wird, die einfach das Front-End lernen. https://codecraft.tv/courses/angular/http/http-with-promises/

208
E. Maggini

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');
129
Slipstream

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.

35
Rajkumar Peter

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

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/*"
]
8
freedev

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.

5
Sunil Kumar

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.

4
Sasa Blagojevic

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

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/

4
Teriblus

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())
2
Rohit Parte

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]
2
hugsbrugs

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" : "*"
           }
     }
}
2
Xu Chen

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

1
Kirill Gusyatin

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

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

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

1

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() { }
1
w00ngy

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

0
Shubham Pandey