jquery - Warum erhält mein JavaScript bei der angeforderten Ressource einen Fehler "Kein Zugriff-Steuerelement-Zulassen-Ursprung", wenn Postman dies nicht tut?




cors restful-authentication same-origin-policy flask-restless (25)

Ich versuche, die Autorisierung mit JavaScript zu machen, indem ich mich mit der in Flask eingebauten RESTful API . Wenn ich die Anfrage mache, erhalte ich den folgenden Fehler:

XMLHttpRequest kann http: // myApiUrl / login nicht laden. Kein 'Access-Control-Allow-Origin'-Header ist auf der angeforderten Ressource vorhanden. Origin 'null' ist daher nicht erlaubt.

Ich weiß, dass die API oder Remote-Ressource die Kopfzeile festlegen muss, aber warum hat es funktioniert, als ich die Anfrage über die Chrome-Erweiterung Postman ?

Dies ist der Anforderungscode:

$.ajax({
    type: "POST",
    dataType: 'text',
    url: api,
    username: 'user',
    password: 'pass',
    crossDomain : true,
    xhrFields: {
        withCredentials: true
    }
})
    .done(function( data ) {
        console.log("done");
    })
    .fail( function(xhr, textStatus, errorThrown) {
        alert(xhr.responseText);
        alert(textStatus);
    });

Answers

I got this error with $http.get in Angular. I needed to use $http.jsonp instead.


Just to mention another way of "bypassing" it - AJAX proxy. Send request to your server to fetch the data from another origin and send the request back to you.

I prefer this approach over JSONP because it has some potential security issues.


Wenn Sie Entity Framework verwenden , scheint dieser Fehler manchmal selbst dann ausgelöst zu werden, wenn Sie CORS aktiviert haben. Ich habe herausgefunden, dass der Fehler aufgrund einer fehlenden Finalisierung der Abfrage aufgetreten ist. Ich hoffe, dass dies anderen in der gleichen Situation helfen wird.

Der folgende Code kann die XMLHttpRequest cannot load http://myApiUrl/login. No 'Access-Control-Allow-Origin' header is present on the requested resource. XMLHttpRequest cannot load http://myApiUrl/login. No 'Access-Control-Allow-Origin' header is present on the requested resource. Error:

using (DBContext db = new DBContext())
{
    return db.Customers.Select(x => new
    {
        Name = x.Name,
        CustomerId = x.CustomerId,
    });
}

Um es zu beheben, ist ein Finalisierungsaufruf wie .ToList() oder .FirstOrDefault() am Ende der Abfrage erforderlich, etwa so:

using (DBContext db = new DBContext())
{
    return db.Customers.Select(x => new
    {
        Name = x.Name,
        CustomerId = x.CustomerId,
    }).ToList();
}

Most of these answers tell users how to add CORS headers to a server they control.

However, if you need data from a server you don't control in a webpage, one solution is to create a script tag on your page, set the src attribute to the api endpoint that doesn't have CORS headers, then load that data onto the page:

window.handleData = function(data) {
  console.log(data)
};

var script = document.createElement('script');
script.setAttribute('src','https://some.api/without/cors/headers.com&callback=handleData');
document.body.appendChild(script);

I have resolved this by enabling CORS for the client URL accessing the web API, and it worked successfully.

Beispielsweise:

[EnableCors(origins: "http://clientaccessingapi.com", headers: "*", methods: "*")]

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin ' https://sx.xyz.com ' is therefore not allowed access.

I had also faced a similar problem with Cross Domain Data Exchange in the Ajax response as error undefined . But the response in header was Status Code:200 OK

Failed to load https://www.Domain.in/index.php?route=api/synchronization/checkapikey:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
Origin 'https://sx.xyz.in' is therefore not allowed access.

The solution to get around it: In my case it was to call the function checkapikey() via Ajax to another domain and get the response with data to where the call has been made:

if (($this->request->server['REQUEST_METHOD'] == 'POST') && isset($this->request->server['HTTP_ORIGIN'])) {

        $this->response->addHeader('Access-Control-Allow-Origin: ' . $this->request->server['HTTP_ORIGIN']);
        $this->response->addHeader('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS');
        $this->response->addHeader('Access-Control-Max-Age: 1000');
        $this->response->addHeader('Access-Control-Allow-Credentials: true');
        $this->response->addHeader('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With');

        $headers = getallheaders();
...
}

Populäre Frage - Eine andere Sache, die man sich ansehen sollte, wenn man so weit gelesen hat und nichts anderes geholfen hat. Wenn Sie ein CDN wie Akamai, Limelight oder ähnliches haben, sollten Sie den Cache-Schlüssel überprüfen, den Sie für den URI der Ressource haben. Wenn es den Origin-Header-Wert nicht enthält, geben Sie möglicherweise eine Antwort zurück, die bei Anforderung von einem anderen Ursprung zwischengespeichert wird. Wir haben gerade einen halben Tag damit verbracht, das zu debuggen. Die CDN-Konfiguration wurde so aktualisiert, dass sie nur den Ursprungswert für einige ausgewählte Domänen enthält und für alle anderen auf null setzt. Dies scheint zu funktionieren und erlaubt Browsern aus unseren bekannten Domains, unsere Ressourcen zu sehen. Sicherlich sind alle anderen Antworten Voraussetzungen, um hierher zu kommen, aber wenn das CDN der erste Sprung von Ihrem Browser ist, ist dies etwas zu überprüfen.

In unserem Fall konnten wir einige Anfragen sehen, die zu unserem Service führten, aber nicht annähernd das Volumen, das die Site aussendete. Das hat uns auf das CDN hingewiesen. Wir konnten zurückgehen und feststellen, dass die ursprüngliche Anforderung von einer direkten Anfrage geliefert wurde, nicht Teil eines Browser-AJAX-Aufrufs und der Antwort-Header Access-Control-Allow-Origin nicht enthalten war. Anscheinend hat der CDN diesen Wert zwischengespeichert. Die Akamai CDN-Konfiguration, die den Origin-Anforderungsheader-Wert als Teil der Übereinstimmung berücksichtigt, scheint es für uns funktionieren zu lassen.


Wenn ich es richtig verstanden habe, machst du eine XMLHttpRequest zu einer anderen Domain, als deine Seite ist. Der Browser blockiert es also, da es aus Sicherheitsgründen normalerweise eine Anfrage im selben Ursprung erlaubt. Sie müssen etwas anderes tun, wenn Sie eine domänenübergreifende Anfrage durchführen möchten. Ein Tutorial dazu, wie man das erreicht, ist die Verwendung von CORS .

Wenn Sie Postbote verwenden, sind sie nicht durch diese Richtlinie eingeschränkt. Zitat aus Cross-Origin XMLHttpRequest :

Normale Webseiten können das XMLHttpRequest-Objekt verwenden, um Daten von Remoteservern zu senden und zu empfangen, sie sind jedoch durch die gleiche Ursprungsrichtlinie eingeschränkt. Erweiterungen sind nicht so begrenzt. Eine Erweiterung kann mit Remote-Servern außerhalb ihres Ursprungs kommunizieren, solange sie zuerst die ursprungsübergreifenden Berechtigungen anfordert.


Ich hatte ein Problem damit, als ich AngularJS benutzte, um auf meine API zuzugreifen. Dieselbe Anfrage funktionierte in SoapUI 5.0 und ColdFusion. Meine GET-Methode hatte bereits den Access-Control-Allow-Origin-Header.

Ich habe herausgefunden, dass AngularJS eine OPTIONS-Anfrage "Probe" macht . ColdFusion generiert standardmäßig die OPTIONS-Methode, aber diese Header sind nicht besonders umfangreich. Der Fehler wurde als Reaktion auf diesen OPTIONS-Aufruf generiert und nicht auf meinen absichtlichen Aufruf von GET. Nachdem ich die Option OPTIONS zu meiner API hinzugefügt habe, wurde das Problem behoben.

<cffunction name="optionsMethod" access="remote" output="false" returntype="any" httpmethod="OPTIONS" description="Method to respond to AngularJS trial call">
    <cfheader name="Access-Control-Allow-Headers" value="Content-Type,x-requested-with,Authorization,Access-Control-Allow-Origin"> 
    <cfheader name="Access-Control-Allow-Methods" value="GET,OPTIONS">      
    <cfheader name="Access-Control-Allow-Origin" value="*">      
    <cfheader name="Access-Control-Max-Age" value="360">        
</cffunction>

For Opera (it works the same as Chrome ), I started the browser with this command:

opera --user-data-dir="~/Downloads/opera-session" --disable-web-security

The problem is solved! Now I can work on a local HTML file (on my hard disk drive) and call Ajax requests to remote origins in the same file.

Note 1: You can give any folder in your home directory as --user-data-dir.

Note 2: Tested on Debian 8 (Jessie)/Opera 39

When you start normally (without the parameters above), the same request falls into the error code block.


On my website (based on .NET) I've just added this:

<system.webServer>
 <httpProtocol>  
    <customHeaders>  
     <add name="Access-Control-Allow-Origin" value="*" />  
     <add name="Access-Control-Allow-Headers" value="Content-Type" />  
     <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />  
    </customHeaders>  
  </httpProtocol>         
</system.webServer>

Big thanks to this video.


https://github.com/Rob--W/cors-anywhere/ stellt (Node.js) Code zur Verfügung, mit dem Sie Ihren eigenen CORS-Proxy einrichten und ausführen können. Es wird aktiv verwaltet und bietet eine Reihe von Funktionen zur Steuerung des Proxy-Verhaltens, die über das einfache Senden der richtigen Access-Control-* Response-Header Access-Control-* .

developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS enthält Details, wie Browser ursprungsübergreifende Anfragen bearbeiten, die clientseitige Web-Anwendungen aus JavaScript erstellen und für welche Header Sie das Senden konfigurieren müssen der Server, zu dem die Anfrage gemacht wird, wenn Sie können.

Wenn eine Site, an die Sie eine Anfrage stellen und eine Antwort erhalten Access-Control-Allow-Origin Antwort Access-Control-Allow-Origin Antwortheader nicht zurückgibt, blockieren Browser immer Cross-Origin-Anfragen, die direkt von Ihrem Client an ihn gerichtet werden JavaScript-Code aus der Arbeit. Wenn also die Site nicht eine ist, die Sie steuern und für die Sie das Verhalten konfigurieren können, funktioniert in diesem Fall nur die Proxy-Verarbeitung der Anforderungen - entweder über Ihren eigenen Proxy, den Sie selbst ausführen, oder über einen offenen Proxy.

Wie in anderen Kommentaren hier erwähnt, gibt es gute Gründe, einem offenen Proxy mit Ihren Anfragen nicht zu vertrauen. Das heißt, wenn Sie wissen, was Sie tun, und Sie entscheiden, dass ein offener Proxy für Ihre Bedürfnisse funktioniert, ist https://cors-anywhere.herokuapp.com/ eine, die zuverlässig verfügbar ist, aktiv gepflegt wird, und eine Instanz der läuft https://github.com/Rob--W/cors-anywhere/ code.

Wie bei anderen hier erwähnten offenen Proxies (von denen einige zumindest nicht mehr verfügbar zu sein scheinen), ist es so, dass Ihr Client-Code eine Anfrage direkt an zB http://foo.com sendet http://foo.com senden Sie es an https://cors-anywhere.herokuapp.com/http://foo.com und der Proxy fügt der Antwort, die der Browser sieht, die erforderlichen Access-Control-* Header hinzu.


Dies ist kein Fix für die Produktion oder wenn dem Client eine Anwendung angezeigt werden soll. Dies ist nur hilfreich, wenn sich die UI- und Backend- Entwicklung auf verschiedenen Servern befinden und sie sich in der Produktion auf demselben Server befinden. Beispiel: Bei der Entwicklung von UI für eine Anwendung, wenn diese lokal getestet werden muss, um sie auf den Backend-Server zu verweisen, ist dies in diesem Szenario die perfekte Lösung. Für eine Produktionsreparatur müssen CORS-Header zum Backend-Server hinzugefügt werden, um den Cross-Origin-Zugriff zu ermöglichen.

Der einfache Weg ist, einfach die Erweiterung in Google Chrome hinzuzufügen, um den Zugriff mit CORS zu ermöglichen.

( https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?hl=en-US )

Aktivieren Sie diese Erweiterung nur dann, wenn Sie den Zugriff auf keine Header-Anforderung "Zugriffssteuerung - Zulassen" zulassen möchten.

Oder

Fügen Sie diesen Befehl in Windows in das Ausführungsfenster ein

chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security

Dadurch wird ein neuer Chrome- Browser geöffnet, der den Zugriff auf die Header-Anfrage "access-control-allow-origin" ermöglicht .


Versuchen Sie XDomain ,

Zusammenfassung: Eine reine JavaScript CORS Alternative / Polyfill. Keine Serverkonfiguration erforderlich - fügen Sie einfach eine proxy.html in der Domäne hinzu, mit der Sie kommunizieren möchten. Diese Bibliothek verwendet XHook, um alle XMLHttpRequest zu haken, also sollte XDomain in Verbindung mit irgendeiner Bibliothek arbeiten.


Basierend auf der Antwort von shruti habe ich eine Verknüpfung des Chrome-Browsers mit benötigten Argumenten erstellt:


Es ist sehr einfach zu lösen, wenn Sie PHP . Fügen Sie am Anfang Ihrer PHP-Seite das folgende Skript hinzu, das die Anfrage bearbeitet:

<?php header('Access-Control-Allow-Origin: *'); ?>

Warnung: Dies enthält ein Sicherheitsproblem für Ihre PHP-Datei, das von Angreifern aufgerufen werden könnte. Sie müssen Sitzungen und Cookies zur Authentifizierung verwenden, um Ihre Datei / Ihren Dienst gegen diesen Angriff zu schützen. Ihr Dienst ist anfällig für Cross-Site-Request-Forgery (CSRF).

Wenn Sie Node-red , müssen Sie CROS in der Datei node-red/settings.js zulassen, indem Sie die folgenden Zeilen unkommentieren:

// The following property can be used to configure cross-origin resource sharing
// in the HTTP nodes.
// See https://github.com/troygoode/node-cors#configuration-options for
// details on its contents. The following is a basic permissive set of options:
httpNodeCors: {
 origin: "*",
 methods: "GET,PUT,POST,DELETE"
},

In meinem Fall habe ich JEE7 JAX-RS benutzt und die folgenden Tricks funktionierten perfekt für mich:

@GET
    @Path("{id}")
    public Response getEventData(@PathParam("id") String id) throws FileNotFoundException {
        InputStream inputStream = getClass().getClassLoader().getResourceAsStream("/eventdata/" + id + ".json");
        JsonReader jsonReader = Json.createReader(inputStream);
        return Response.ok(jsonReader.readObject()).header("Access-Control-Allow-Origin", "*").build();
    }

Wenn Sie Node.js , versuchen Sie es:

app.use(function(req, res, next) {
    res.header("Access-Control-Allow-Origin", "*");
    res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
    next();
});

Weitere Informationen: CORS auf ExpressJS


Ich konnte erfolgreich mit htaccess (in meinem Fall für Fonts) lösen, aber offensichtlich, OP fragt wenig anders. Sie können jedoch das FileMatch-Muster verwenden und eine beliebige Erweiterung hinzufügen, so dass kein Cros-Fehler angezeigt wird.

<IfModule mod_headers.c>
  <FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|font.css|css)$">
    Header set Access-Control-Allow-Origin "*"
  </FilesMatch>
</IfModule>

https://httpd.apache.org/docs/2.4/mod/core.html#filesmatch


Es gibt ein domänenübergreifendes Problem mit Ajax. Sie müssen sicher sein, dass Sie auf Ihre Dateien auf demselben http:// Pfad ohne www. zugreifen www. (oder Zugriff von http://www. und post auf den gleichen Pfad einschließlich www. ), die der Browser als eine andere Domäne beim Zugriff über ein www. Pfad, so sehen Sie, wo das Problem liegt. Sie posten in einer anderen Domäne und der Browser blockiert den Datenfluss aufgrund des Ursprungsproblems.

Wenn die API nicht auf demselben Host platziert wird, von dem Sie anfordern, wird der Fluss blockiert und Sie müssen eine andere Möglichkeit finden, um mit der API zu kommunizieren.


Ich wünschte, jemand würde diese Seite mit mir vor langer Zeit teilen http://cors.io/ es hätte eine Menge Zeit im Vergleich zum Bauen und Verlassen auf meinen eigenen Proxy gespeichert. Wenn Sie jedoch in die Produktion wechseln, ist es am besten, einen eigenen Proxy zu haben, da Sie immer noch alle Aspekte Ihrer Daten kontrollieren.

Alles was du brauchst:

https://cors.io/?http://HTTP_YOUR_LINK_HERE


weil
$ .ajax ({type: "POST" - Ruft OPTIONEN auf
$ .post ( - ruft POST auf

beide Postman-Postfächer sind unterschiedlich, aber wenn wir anrufen, wird es "OPTIONEN" sein

Für c # -Webdienste - webapi

Fügen Sie den folgenden Code in Ihre Datei web.config unter dem Tag <system.webServer> ein. Das wird funktionieren

<httpProtocol>
    <customHeaders>
        <add name="Access-Control-Allow-Origin" value="*" />
    </customHeaders>
</httpProtocol>

Bitte vergewissere dich, dass du keinen Fehler beim Ajax-Aufruf machst

jQuery

$.ajax({
    url: 'http://mysite.microsoft.sample.xyz.com/api/mycall',
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded'
    },
    type: "POST", /* or type:"GET" or type:"PUT" */
    dataType: "json",
    data: {
    },
    success: function (result) {
        console.log(result);    
    },
    error: function () {
        console.log("error");
    }
});

Angular 4 Problem finden Sie unter: http://www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/

Hinweis: Wenn Sie Inhalte von einer Drittanbieter-Website herunterladen möchten, hilft Ihnen dies nicht weiter . Sie können den folgenden Code ausprobieren, aber nicht JavaScript.

System.Net.WebClient wc = new System.Net.WebClient();
string str = wc.DownloadString("http://mysite.microsoft.sample.xyz.com/api/mycall");

Ich hatte die folgende Konfiguration, was zu dem gleichen Fehler führte, wenn Antworten vom Server angefordert wurden.

Serverseitig: SparkJava -> stellt die REST-API zur Verfügung
Client-seitig: ExtJs6 -> bietet Browser-Rendering

Auf der Serverseite musste ich dies zur Antwort hinzufügen:

Spark.get("/someRestCallToSpark", (req, res) -> {
    res.header("Access-Control-Allow-Origin", "*"); //important, otherwise its not working 
    return "some text";
 });

Auf der Client-Seite musste ich das zur Anfrage hinzufügen :

Ext.Ajax.request({
    url: "http://localhost:4567/someRestCallToSpark",
    useDefaultXhrHeader: false, //important, otherwise its not working
    success: function(response, opts) {console.log("success")},
    failure: function(response, opts) {console.log("failure")}
});

Viele Male passiert mir das von Javascript zu meiner PHP-API, weil einer von ein paar Gründen. Ich vergesse den <?php header('Access-Control-Allow-Origin: *'); ? <?php header('Access-Control-Allow-Origin: *'); ? ist ein. Dies ist hilfreich für den Cross-Sub-Domain-Zugriff. Ein weiterer Grund ist, dass ich in der jQuery ajax Anfrage einen spezifischen dataType spezifiziere und einen anderen dataType zurückgebe, so dass ein Fehler ausgegeben wird.

Das letzte und bekannteste Argument für diesen Fehler ist ein Parse-Fehler auf der Seite, die Sie anfordern. Wenn Sie diese Seiten-URL in Ihrem Browser mehr als wahrscheinlich treffen, werden Sie einen Analysefehler sehen, und Sie werden eine Zeilennummer haben, um das Problem zu beheben.

Ich hoffe, das hilft jemandem. Ich brauchte jedes Mal eine Weile, um das zu debuggen, und ich wünschte, ich hätte eine Checkliste mit Dingen, die ich überprüfen müsste.






jquery cors restful-authentication same-origin-policy flask-restless