Perché il mio JavaScript ottiene “No” l’intestazione Access-Control-Allow-Origin “è presente sulla risorsa richiesta” errore quando Postman non lo fa?

Sto cercando di fare l’authorization usando JavaScript connettendomi all’API RESTful costruita in Flask . Tuttavia, quando faccio la richiesta, ottengo il seguente errore:

XMLHttpRequest non può caricare http: // myApiUrl / login . Nessuna intestazione ‘Access-Control-Allow-Origin’ è presente sulla risorsa richiesta. L’origine ‘null’ non è quindi consentita l’accesso.

So che l’API o la risorsa remota deve impostare l’intestazione, ma perché ha funzionato quando ho fatto la richiesta tramite l’estensione Postman di Chrome?

Questo è il codice di richiesta:

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

Se ho capito bene, stai facendo un XMLHttpRequest su un dominio diverso da quello su cui è triggers la tua pagina. Quindi il browser lo sta bloccando in quanto di solito consente una richiesta nella stessa origine per motivi di sicurezza. Devi fare qualcosa di diverso quando vuoi fare una richiesta interdominio. Un tutorial su come ottenere ciò sta usando CORS .

Quando si utilizza il postino non sono limitati da questa politica. Citato da Cross-Origin XMLHttpRequest :

Le normali pagine Web possono utilizzare l’object XMLHttpRequest per inviare e ricevere dati da server remoti, ma sono limitati dalla stessa politica di origine. Le estensioni non sono così limitate. Un’estensione può comunicare con server remoti al di fuori dell’origine, purché prima richieda autorizzazioni di origine incrociata.

Questa non è una correzione per la produzione o quando l’applicazione deve essere mostrata al client, questo è utile solo quando lo sviluppo dell’interfaccia utente e del backend sono su server diversi e in produzione sono effettivamente sullo stesso server. Ad esempio: Durante lo sviluppo dell’interfaccia utente per qualsiasi applicazione, se è necessario testarla localmente indirizzandola al server back-end, in tale scenario questa è la soluzione perfetta. Per la correzione della produzione, le intestazioni CORS devono essere aggiunte al server di back-end per consentire l’accesso all’origine incrociata.

Il modo più semplice è semplicemente aggiungere l’estensione in google chrome per consentire l’accesso utilizzando CORS.

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

Abilita questa estensione ogni volta che vuoi consentire l’accesso a nessuna richiesta di intestazione ‘access-control-allow-origin’ .

O

In Windows, incolla questo comando nella finestra di esecuzione

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

questo aprirà un nuovo browser Chrome che consente l’accesso a nessuna richiesta di intestazione ‘access-control-allow-origin’ .

Se riesci a gestire JSON in cambio, prova a utilizzare JSONP (nota la P alla fine) per parlare tra domini:

 $.ajax({ type: "POST", dataType: 'jsonp', ...... etc ...... 

Ulteriori informazioni su come lavorare con JSONP qui :

L’avvento di JSONP – essenzialmente un consecutivo script di scripting cross-site – ha aperto la porta a potenti mashup di contenuti. Molti siti di rilievo forniscono servizi JSONP, consentendo l’accesso ai propri contenuti tramite un’API predefinita.

È molto semplice da risolvere se usi PHP . Basta aggiungere il seguente script all’inizio della pagina PHP che gestisce la richiesta:

  

Avviso: questo contiene un problema di sicurezza per il file PHP che potrebbe essere chiamato dagli autori di attacchi. devi utilizzare sessioni e cookie per l’autenticazione per impedire il tuo file / servizio contro questo attacco. Il servizio è vulnerabile alla falsificazione di richieste tra siti (CSRF).

Se stai usando Node-red devi permettere a CORS nel file node-red/settings.js di non commentare le seguenti righe:

 // 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" }, 

Vorrei che qualcuno condividesse questo sito con me molto tempo fa http://cors.io/ avrebbe risparmiato un sacco di tempo rispetto a build e fare affidamento sul mio proxy. Tuttavia, quando passi alla produzione, avere il tuo proxy è la soluzione migliore dal momento che controlli ancora tutti gli aspetti dei tuoi dati.

Tutto ciò di cui hai bisogno:

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

Esiste un problema inter-dominio che utilizza Ajax. Devi essere sicuro che stai accedendo ai tuoi file sullo stesso http:// percorso senza www. (o accedere da http://www. e postare allo stesso percorso, incluso www. ) che il browser considera come un altro dominio quando accede tramite www. percorso, quindi vedi dove si trova il problema. Stai postando in un dominio diverso e il browser blocca il stream a causa del problema dell’origine.

Se l’ API non è posizionata sullo stesso host da cui si richiede, il stream viene bloccato e sarà necessario trovare un altro modo per comunicare con l’API.

Se stai usando Node.js , provalo:

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

Ulteriori informazioni: CORS su ExpressJS

Perché
$ .ajax ({tipo: “POST” – Chiamate OPZIONI
$ .post ( – chiama POST

entrambe le chiamate Postman sono diverse “POST” correttamente, ma quando le chiamiamo sarà “OPZIONI”

Per i servizi web c #: webapi

Aggiungi il seguente codice nel tuo file web.config sotto il tag . Questo funzionerà

      

Assicurati di non aver commesso errori nella chiamata ajax

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

Angolare 4 problema per favore riferirsi: http://www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/

Nota: se stai cercando di scaricare contenuti da siti Web di terze parti, questo non ti aiuterà . Puoi provare il seguente codice ma non JavaScript.

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

Prova XDomain ,

Riepilogo: Una pura alternativa CORS JavaScript / polyfill. Non è richiesta alcuna configurazione del server – basta aggiungere un proxy.html sul dominio con cui si desidera comunicare. Questa libreria utilizza XHook per agganciare tutti gli XHR , quindi XDomain dovrebbe funzionare in combinazione con qualsiasi libreria.

Se non vuoi:

  1. Distriggers la sicurezza Web in Chrome
  2. Usa JSONP
  3. Utilizzare un sito di terze parti per redirect le richieste

e sei sicuro che il tuo server ha abilitato CORS allora (prova CORS qui: http://www.test-cors.org/ )

Quindi devi passare il parametro di origine con la tua richiesta. Questa origine DEVE corrispondere all’origine che il tuo browser invia con la tua richiesta.

Puoi vederlo in azione qui: http://www.wikibackpacker.com/app/detail/Campgrounds/3591

La funzionalità di modifica invia una richiesta GET e POST a un dominio diverso per il recupero dei dati. Ho impostato il parametro di origine che risolve il problema. Il back-end è un motore mediaWiki.

tldr: aggiungi il parametro “origine” alle tue chiamate che deve essere il parametro Origin che il tuo browser invia (non puoi spoofare il parametro di origine)

Ho avuto un problema con questo quando ho usato AngularJS per accedere alla mia API. La stessa richiesta ha funzionato in SoapUI 5.0 e ColdFusion. Il mio metodo GET aveva già l’intestazione Access-Control-Allow-Origin.

Ho scoperto che AngularJS effettua una richiesta di OPZIONI di “prova” . ColdFusion, per impostazione predefinita, genera il metodo OPTIONS, ma non ha molto, queste intestazioni in particolare. L’errore è stato generato in risposta a tale chiamata OPTIONS e non alla mia chiamata intenzionale a GET. Dopo aver aggiunto il seguente metodo OPZIONI alla mia API, il problema è stato risolto.

       

Ho avuto la seguente configurazione, risultante nello stesso errore, durante la richiesta di risposte dal server.

Lato server: SparkJava -> fornisce l’API REST
Lato client: ExtJs6 -> fornisce il rendering del browser

Sul lato server ho dovuto aggiungere questo alla risposta:

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

Sul lato client ho dovuto aggiungere questo alla richiesta:

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

In base alla risposta di shruti , ho creato una scorciatoia del browser Chrome con gli argomenti necessari: inserisci la descrizione dell'immagine qui inserisci la descrizione dell'immagine qui

È ansible bypassare il problema utilizzando YQL per proxy la richiesta attraverso i server di Yahoo. Sono solo alcune righe di codice:

 var yql_url = 'https://query.yahooapis.com/v1/public/yql'; var url = 'your api url'; $.ajax({ 'url': yql_url, 'data': { 'q': 'SELECT * FROM json WHERE url="'+url+'"', 'format': 'json', 'jsonCompat': 'new', }, 'dataType': 'jsonp', 'success': function(response) { console.log(response); }, }); 

Ecco il link con una spiegazione: https://vverma.net/fetch-any-json-using-jsonp-and-yql.html

https://github.com/Rob–W/cors-anywhere/ fornisce il codice (Node.js) che puoi utilizzare per configurare ed eseguire il tuo proxy CORS. È mantenuto triggersmente e offre una serie di funzionalità per il controllo del comportamento del proxy oltre al semplice invio delle intestazioni di risposta Access-Control-* corrette.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS ha dettagli per spiegare come i browser gestiscono le richieste di origine incrociata che le applicazioni Web lato client fanno da JavaScript e quali intestazioni è necessario configurare l’invio di il server a cui è stata fatta la richiesta, se ansible.

Nel caso in cui un sito a cui è necessario effettuare una richiesta e ricevere una risposta non restituisca l’intestazione di risposta Access-Control-Allow-Origin , i browser bloccheranno sempre le richieste di origine incrociata inviate direttamente dal client codice JavaScript da lavorare. Pertanto, se il sito non è quello che controlli e puoi configurare il comportamento, l’unica cosa che funzionerà in quel caso è il proxy delle richieste, sia attraverso il tuo proxy che te stesso o attraverso un proxy aperto.

Come menzionato in altri commenti qui, ci sono buone ragioni per non fidarsi di un proxy aperto con le tue richieste. Detto questo, se sai cosa stai facendo e decidi che un proxy aperto funziona per le tue esigenze, https://cors-anywhere.herokuapp.com/ è affidabile, mantenuto triggersmente e che esegue un’istanza del https://github.com/Rob–W/cors-anywhere/ code.

Come con altri proxy aperti menzionati qui (un paio dei quali almeno non sembrano essere più disponibili), il modo in cui funziona è che invece di inviare il codice client a una richiesta direttamente, ad esempio, http://foo.com lo invii a https://cors-anywhere.herokuapp.com/http://foo.com e il proxy aggiunge le intestazioni necessarie di Access-Control-* alla risposta che il browser vede.

Se si utilizza Entity Framework , sembra che a volte questo errore venga generato anche se CORS abilitato. Ho capito che l’errore si è verificato a causa della mancata finalizzazione della query. Spero che questo aiuti gli altri nella stessa situazione.

Il seguente codice può lanciare 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. errore:

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

Per risolvere il problema, è necessaria una chiamata di finalizzazione come .ToList() o .FirstOrDefault() alla fine della query, in questo modo:

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

Nel mio caso stavo usando l’applicazione JEE-JEE J e i seguenti trucchi hanno funzionato perfettamente per me:

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

Sono riuscito a risolvere con successo (nel mio caso per i caratteri) usando htaccess ma, ovviamente, l’OP sta chiedendo poco. Ma puoi usare il pattern di FileMatch e aggiungere qualsiasi estensione in modo che non dia l’errore di cros.

   Header set Access-Control-Allow-Origin "*"   

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

Domanda popolare – Un’altra cosa da guardare se hai letto fino ad ora e nient’altro ha aiutato. Se si dispone di un CDN come Akamai, Limelight o simile, è ansible controllare la chiave di cache che si ha per l’URI della risorsa. Se non include il valore dell’intestazione Origin, è ansible che venga restituita una risposta nella cache quando richiesto da un’altra origine. Abbiamo appena trascorso mezza giornata a eseguire il debug di questo. La configurazione CDN è stata aggiornata per includere solo il valore Origin per alcuni domini selezionati che sono nostri e impostarlo su null per tutti gli altri. Questo sembra funzionare e consente ai browser dei nostri domini conosciuti di visualizzare le nostre risorse. Certamente tutte le altre risposte sono prerequisiti per arrivare qui, ma se il CDN è il primo salto dal tuo browser questo è qualcosa da rivedere.

Nel nostro caso abbiamo potuto vedere alcune richieste che lo hanno reso al nostro servizio, ma non il volume che il sito stava inviando. Questo ci ha indirizzato verso il CDN. Siamo stati in grado di tornare indietro e vedere la richiesta originale è stata fornita da una richiesta diretta, non parte di una chiamata AJAX del browser e l’intestazione di risposta Access-Control-Allow-Origin non è stata inclusa. Apparentemente il CDN ha memorizzato questo valore. Il tweak della configurazione CDN di Akamai per considerare il valore dell’intestazione della richiesta Origin come parte della corrispondenza sembra averlo fatto funzionare per noi.

Per l’API GoLang:

Per prima cosa puoi dare un’occhiata a MDN CORS Doc per sapere cos’è CORS. Per quanto ne so, CORS si occupa di consentire a Origin Of Request di accedere o meno alle risorse del server.

E puoi limitare quale origine della richiesta può accedere al server impostando Access-Control-Allow-Origin Header della risposta del server.

Ad esempio, l’impostazione dell’intestazione seguente in Server Response significa che solo la richiesta inviata da http://foo.example può accedere al server:

 Access-Control-Allow-Origin: http://foo.example 

e in seguito consentire la richiesta inviata da qualsiasi origine (o dominio):

 Access-Control-Allow-Origin: * 

E come noto nel messaggio di errore, requested resource indica la risorsa del server, quindi No 'Access-Control-Allow-Origin' header is present on the requested resource. significa che non hai impostato l’intestazione Access-Control-Allow-Origin nella risposta del server, o forse hai impostato, ma l’origine della richiesta non è in Access-Control-Allow-Origin quindi la richiesta non è consentita:

Nessuna intestazione ‘Access-Control-Allow-Origin’ è presente sulla risorsa richiesta. L’origine ‘null’ non è quindi consentita l’accesso.

In GoLang, utilizzo il pacchetto gorilla/mux per creare un server API su localhost:9091 e consento a CORS di aggiungere "Access-Control-Allow-Origin", "*" all’intestazione della risposta:

 func main() { // API Server Code router := mux.NewRouter() // API route is /people, //Methods("GET", "OPTIONS") means it support GET, OPTIONS router.HandleFunc("/people", GetPeople).Methods("GET", "OPTIONS") log.Fatal(http.ListenAndServe(":9091", router)) } // Method of '/people' route func GetPeople(w http.ResponseWriter, r *http.Request) { // Allow CORS by setting * in sever response w.Header().Set("Access-Control-Allow-Origin", "*") w.Header().Set("Access-Control-Allow-Headers", "Content-Type") json.NewEncoder(w).Encode("OKOK") } 

E io uso JavaScript nel client, in localhost:9092 fare richiesta da Chrome può ottenere con successo “OKOK” dal localhost:9091 server localhost:9091 .

 function GetPeople() { try { var xhttp = new XMLHttpRequest(); xhttp.open("GET", "http://localhost:9091/people", false); xhttp.setRequestHeader("Content-type", "text/html"); xhttp.send(); var response = JSON.parse(xhttp.response); alert(xhttp.response); } catch (error) { alert(error.message); } } 

Inoltre puoi controllare l’intestazione richiesta / risposta da strumenti come Fiddler .

Se ricevi questo messaggio di errore dal browser:

 No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '…' is therefore not allowed access 

quando stai tentando di eseguire una richiesta POST / GET Ajax su un server remoto che è fuori dal tuo controllo, ti preghiamo di dimenticare questa semplice soluzione:

  

È davvero necessario, soprattutto se si utilizza JavaScript solo per eseguire la richiesta Ajax, un proxy interno che accetta la query e la invia al server remoto.

First in your JavaScript code, do an Ajax call to your own server, something like:

 $.ajax({ url: yourserver.com/controller/proxy.php, async: false, type: "POST", dataType: "json", data: data, success: function (result) { JSON.parse(result); }, error: function (xhr, ajaxOptions, thrownError) { console.log(xhr); } }); 

Then, create a simple PHP file called proxy.php to wrap your POST data and append them to the remote URL server as a parameters. I give you an example of how I bypass this problem with the Expedia Hotel search API:

 if (isset($_POST)) { $apiKey = $_POST['apiKey']; $cid = $_POST['cid']; $minorRev = 99; $url = 'http://api.ean.com/ean-services/rs/hotel/v3/list?' . 'cid='. $cid . '&' . 'minorRev=' . $minorRev . '&' . 'apiKey=' . $apiKey; echo json_encode(file_get_contents($url)); } 

By doing:

 echo json_encode(file_get_contents($url)); 

You are just doing the same query, but on the server side and after that, it should work fine.

Answer copied and pasted from NizarBsb

A lot of times this happens to me from javascript to my php api, because one of a few reasons. I forget to put the is one. This is helpful for cross sub domain access. Another reason, is because in jQuery ajax request I am specifying a specific dataType and returning a different dataType, so it throws an error.

The Last and most prominent reasoning for this error is there is a parse error on the page you are requesting. If you hit that page url in your browser than more than likely you will see a parse error and you will have a line number to address the issue.

Spero che questo aiuti qualcuno. It took me a while each time to debug this and I wish I had a checklist of things to verify.

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

CORS is for you.

CORS is “Cross Origin Resource Sharing” and is a way to send a cross-domain request. Now the XMLHttpRequest2 and Fetch API both support CORS.

But it has its limits. Server need to specific claim the Access-Control-Allow-Origin , and it can not be set to ‘*’.

And if you want any origin can send request to you, you need JSONP (also need to set Access-Control-Allow-Origin , but can be ‘*’).

For lots of request way if you don’t know what to choose, I think you need a fully functional component to do that. Let me introduce a simple component catta


If you are using a modern browser (> Internet Explorer9, Chrome, Firefox, Edge, etc.), it is very recommended you use a simple, but beautiful component, https://github.com/Joker-Jelly/catta . It has no dependencies, is less than 3 KB, and it supports Fetch, Ajax and JSONP with same dead-simple syntax and options.

 catta('./data/simple.json').then(function (res) { console.log(res); }); 

It also supports all the way to import to your project, like ES6 module, CommonJS and even in HTML.

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

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

          

Big thanks to this video.

For Ruby on Rails server in application_controller.rb , add this:

 after_action :cors_set_access_control_headers def cors_set_access_control_headers headers['Access-Control-Allow-Origin'] = '*' headers['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS' headers['Access-Control-Allow-Headers'] = '*' end 

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

Maybe is it a litte bit complicated but you can use a web server to route the request. With nodejs you havent this problem. I am not an expert in node js. So i dont know if this is clean code.

But this works for me

Here is a little exmaple:

NODE JS

 var rp = require('request-promise'); var express = require('express'), app = express(), port = process.env.PORT || 3000; var options = { method: 'POST', uri: 'http://api.posttestserver.com/post', body: { some: 'payload' }, json: true // Automatically stringifies the body to JSON }; app.get('/', function (req, res) { rp(options) .then(function (parsedBody) { res.send(parsedBody) }) .catch(function (err) { res.send(err) }); }); app.listen(port); 

JS

 axios.get("http://localhost:3000/").then((res)=>{ console.log('================res===================='); console.log(res); console.log('===================================='); }) 

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

Here is a screenshot

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