Axios: Cross-Site POST funktioniert nicht

Außerdem setze ich withCredentials in der config auf true.

Ich bin gerade auch auf dieses Problem gestoßen und es scheint nur bei mir auf dem Mac zu passieren. Ich verbrachte gute 3 Tage und Nächte damit, mein Netzwerk zu debuggen, und beschloss aus einer Laune heraus, dies mit einer Vanilla-XHR-Anfrage zu versuchen, und stellte fest, dass das Problem nicht mein Netzwerk war, sondern Axios.

Ich mache auch Cross-Site-Anfragen mit auf "true" gesetzten Anmeldeinformationen. Wenn Sie sich die Netzwerkanfrage ansehen, erhalten Sie eine ERR_EMPTY_RESPONSE und es ist, als wäre die Anfrage fehlgeschlagen, bevor sie den Browser verlassen hat.

Das ist meine Konfiguration:

const myApi = axios.create({
  baseURL: 'http://someUrl/someEndpoint',
  timeout: 10000,
  withCredentials: true,
  transformRequest: [(data) => JSON.stringify(data.data)],
  headers: {
    'Accept': 'application/json',
    'Content-Type': 'application/json',
  }
});'

Bei Gelegenheit werde ich versuchen, das weiter zu prüfen.

Oh gut, ich bin nicht verrückt. :) Bitte prüfen Sie dies, wenn möglich.

Es stellte sich heraus, dass mein Problem nichts mit Axios zu tun hatte. Cisco Anyconnect blockierte Optionsanfragen von meinem Computer... aus Gründen?

Domänenübergreifende Anfragen erfordern keine zusätzliche Konfiguration. Es wird auf die Verwendung von XDomainRequest für ältere IE zurückgegriffen. https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js#L22

Können Sie nähere Angaben machen? Welcher Browser, Betriebssystem, Version von Axios, Fehlermeldungen.

Ich kann nicht für Jenny sprechen, aber etwas Bestimmtes in dieser Bibliothek führt dazu, dass Anfragen von der Cisco Anyconnect-Standardsicherheit blockiert werden, was bedeutet, dass dies möglicherweise auch andere Sicherheitseinstellungen tun. Ich versuche, das aufzuspüren, aber bisher kein Glück.

Dies kann durch eine Cross-Site-Anfrage auf einem Mac reproduziert werden, der mit Cisco Anyconnect und möglicherweise anderen VPN-Clients installiert ist.

Mein Umfeld ist:

• Axios 0.8.1
• El Capitan
• Chrom
• Fehlermeldung: "Auf der angeforderten Ressource ist kein 'Access-Control-Allow-Origin'-Header vorhanden. Origin ' http://localhost :3000' hat daher keinen Zugriff."

Beachten Sie, dass dieselbe Anfrage mit curl funktioniert.

Danke, dass Sie sich das angeschaut haben!

Bei CORS wird eine Preflight-Anfrage an den Server gestellt, um zu sehen, ob die Anfrage zulässig ist. Sie müssen Ihren Server auf Anfragen mit OPTIONS als Anfragemethode reagieren lassen, indem Sie den Header Acces-Control-Allow-Origin: * der Anfragen von jedem Ursprung zulässt. Alternativ können Sie nur bestimmte Ursprünge Acces-Control-Allow-Origin: http://example.com zulassen.

Ja ich verstehe das. Aber der Server gehört nicht mir. Ich verwende ein Baas (Backend-as-a-Service). Und sie haben meine Domain bereits zur Zulassungsliste hinzugefügt. Ich habe überprüft, dass andere Leute, die besagtes Baas verwenden, solche Probleme nicht hatten.

Ich gehe nur die Fehlermeldung aus, die Sie bereitgestellt haben, aber basierend darauf hört es sich nicht so an, als ob die Dinge für Sie funktionieren würden. Die Verwendung von curl würde nicht fehlschlagen, da die Cross-Origin-Sicherheit nur eine Einschränkung innerhalb des Browsers ist.

Können Sie den Netzwerk-Tab in Ihrem Browser öffnen und teilen, was Sie als Antwort auf die OPTIONS-Anfrage erhalten? Hoffentlich hilft das Anzeigen der Antwortdaten und -header beim Debuggen dieses Problems.

Danke

Hier die Überschriften:

Hier sind die Antwortheader von GitHub, wenn ich axios verwende, um mein Benutzerprofil von ihrer API abzurufen:

Sie können sehen, dass GitHub die Access-Control-Allow-Origin: * hinzufügt. In der Antwort Ihres Baas fehlen Header des Typs Access-Control .

Ich sehe, ich sehe, hm. Sorry für die super späte Antwort. Lassen Sie mich das etwas genauer untersuchen. Vielen Dank.

Ich bin mir nicht sicher, ob das, was ich sehe, zusammenhängt oder nicht. Grundsätzlich kann ich eine Auth-Anfrage an unseren Remote-Server senden und ein Cookie zurückbekommen, aber dann senden nachfolgende Aufrufe an den Server die Cookies _nicht_ mit, was zu einem Fehler führt.

Hier sind die Header des POST Aufrufs zum Anmelden:

Und jetzt ein Folgeanruf von GET :

Die unter origin aufgeführte IP-Adresse ist meine eigene, das sollte also kein Problem sein. Sollte dies der falsche Ort dafür sein, erstelle ich gerne eine neue Ausgabe, oder füge der entsprechenden bestehenden bei.

Als neue Falte; Ich habe einen nachfolgenden GET Anruf nur mit XHR getestet, und der Cookie wird problemlos gesendet. Derselbe Anruf über Axios führt jedoch zu demselben Problem, das ich oben erwähnt habe.

Pfui. Bitte ignorieren - ich habe die Dinge nicht wie erwartet über Axios gesendet :)

Ich stehe auch vor dem gleichen Problem.
OPTIONEN Anruf geht durch, aber POST-Anrufe bleiben in Cors stecken.
http://stackoverflow.com/questions/36907693/axios-cors-issue-with-github-oauth-not-getting-access-token

Wie wird ein so RIESIGES Problem nicht angegangen?

+1

+1

+1

+1

+1

+1

+1

@dsacramone, was ist das Problem, das Sie sehen? Es scheint, dass die meisten gemeldeten Probleme Serverprobleme oder Fehlalarme sind. Wenn es einen reproduzierbaren Fehler gibt, den ich mir ansehen kann, arbeite ich gerne an einer Lösung.

bekomme das auch

XMLHttpRequest kann https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish nicht laden http://localhost :3000' hat daher keinen Zugriff.

auch mit fetch to note bekommen. Ich denke, sein Chrome hat vor kurzem die Richtlinien zur Anforderungseinstellung strenger gemacht, ich denke, es wird eine Art Header benötigen (nicht sicher, was).

Hier ist ein Beispiel (beide über https bereitgestellt)

Beispiel 1 - Funktioniert einwandfrei

axios.get('https://randomuser.me/api/')
  .then(function (response) {
    console.log(response.data);
  })
  .catch(function (error) {
    console.log(error);
  });

Beispiel 2 - Funktioniert nicht - Fehler angezeigt?

axios.get('https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish')
  .then(function (response) {
    console.log(response.data);
  })
  .catch(function (error) {
    console.log(error);
  });

hier ist die fehlerantwort

[object Error] {
  config: [object Object] {
    data: undefined,
    headers: [object Object] { ... },
    maxContentLength: -1,
    method: "get",
    timeout: 0,
    transformRequest: [object Object] { ... },
    transformResponse: [object Object] { ... },
    url: "https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish",
    validateStatus: function validateStatus(status) {
      return status >= 200 && status < 300;
    },
    xsrfCookieName: "XSRF-TOKEN",
    xsrfHeaderName: "X-XSRF-TOKEN"
  },
  response: undefined
}

etwas, das relevant sein könnte, befindet sich in der transformResponse ? Ich frage mich, was das PROTECTION_PREFIX-Bit bedeutet?

[object Object] {
  0: function transformResponse(data) {
      /*eslint no-param-reassign:0*/
      if (typeof data === 'string') {
        data = data.replace(PROTECTION_PREFIX, '');
        try {
          data = JSON.parse(data);
        } catch (e) { /* Ignore */ }
      }
      return data;
    }
}

sogar versuchen

Modus: 'kein Kors'
beim Abrufen wird immer noch dieser Fehler angezeigt

Ich bin mir sicher, dass die Antworten ziemlich einfach sind und nur eine Art Header benötigen, nur nicht sicher, was, wird weiter herumspielen.

Die Wikipedia-API könnte nur ein wackeliges Beispiel sein, derselbe Fehler bei anderen?

Ich lösche diesen Code, kann funktionieren: axios.defaults.withCredentials = true

Ich habe die Wikipedia-API, um mit jsonp gut zu

var jsonp = require('jsonp');

// search for 'frog'
jsonp('https://en.wikipedia.org/w/api.php?action=opensearch&search=frog&format=json', null, function (err, data) {
  if (err) {
    console.error(err.message);
  } else {
    console.log(data);
  }
});

Keine zusätzlichen Konfigurationen erforderlich.

Bekomme den gleichen Fehler mit Axios. Hier ist meine React-Komponente:

import React, { Component } from 'react'
import axios from 'axios'

export default class User extends Component {
  constructor(props){
    super(props)

    // axios.defaults.withCredentials = true

    const config = {
    method: 'get',
    url: 'https://api.airbnb.com/v2/users/2917444?client_id=3092nxybyb0otqw18e8nh5nty&_format=v1_legacy_show',
    headers: {'X-Requested-With': 'XMLHttpRequest'},
    responseType: 'json',
    withCredentials: true,
  }

    axios.request(config)
      .then(response => { console.log('response: ', response) });

  }

  render() {
    return (
      <div>User</div>
    )
  }
}

_Hinweis: Ich kann die API mit Node-Request perfekt erreichen._

Ich habe denselben Fehler wie @Sinistralis . Auf der neuesten Chrome-Version in Mac OSX erhalte ich net::ERR_EMPTY_RESPONSE für CORS-Anfragen, die richtig gestellt werden (mein Server verarbeitet alle CORS-Header einschließlich OPTIONS einwandfrei). Es ist seltsam, denn auf iOS10 Safari funktioniert genau der gleiche Code ohne Probleme. Ich werde versuchen, ein wenig mehr auf eigene Faust zu untersuchen, um zu sehen, wie das Problem gelöst werden könnte.

Auf einem älteren Mac (10.11) mit der neuesten Chrome-Version kann ich diesen Fehler nicht mit genau demselben Code reproduzieren. Das ist in der Tat sehr seltsam. Sie können möglicherweise reproduzieren, indem Sie diese sehr einfache App besuchen: http://lights.suyashkumar.com und die Konsole überprüfen (Code ist hier . Auf einigen Computern wird kein Fehler angezeigt und Sie werden zur Anmeldung weitergeleitet. Auf anderen Es wird nicht weitergeleitet und Sie bleiben auf der Hauptseite.

Habe meinen Fehler gelöst. Für mich war es ein Problem mit der Zuweisung eines Headers in config.headers mit einem Nullwert beim Anwendungsstart (es zieht einen Wert aus dem lokalen Speicher, und zunächst ist nichts da). Das Zuweisen des Werts zu einer leeren Zeichenfolge, wenn der Wert null ist, löst das Problem. Ich frage mich, ob dies etwas ist, das innerhalb von Axios behandelt werden kann oder sollte (nicht sicher, ob es einen Wert hat, Null-Header an xhr zu übergeben, wenn es _manchmal_ bricht).

Bei anderen mit einem ähnlichen Problem habe ich festgestellt, dass einige VPN-Clients auch OPTIONS-Anfragen blockieren können (siehe hier ).

Der irreführende CORS-Fehler ist immer noch in axios. Das Polyfill fetch unterstützt mode: 'no-cors' , um dieses Problem zu beheben.

Wir müssen diese Art von Anfragen durchführen, um Anfragen an Maschinen in anderen Umgebungen, die wir betreiben, sowie auf derselben Maschine an verschiedenen Ports zu stellen!

@dreki Bitte geben Sie die Beschreibung des von Ihnen erwähnten Problems an.

Sie können auf der Client-Seite nichts tun, wenn der Server einfach keine Anfragen von Ihrem Ursprung akzeptiert. Wenn du könntest, hätten wir hier ein riesiges Sicherheitsleck (und mit "wir" meine ich das ganze Internet)...

Ich denke, Axios agiert und reagiert hier total konform.

Der wichtige Response-Header ist Access-Control-Allow-Origin der grundsätzlich die gültigen Ursprünge festlegt, die diesen serverseitigen Dienst aufrufen dürfen. Wenn Ihr Client von keinem dieser konfigurierten Ursprünge aus anruft, wird die Anfrage mit einem Konsolenfehler wie diesem abgelehnt:

XMLHttpRequest kann http://localhost :8080/v1/api/search?q=candles nicht laden. Auf der angeforderten Ressource ist kein Header 'Access-Control-Allow-Origin' vorhanden. Origin ' http://localhost :9999' hat daher keinen Zugriff.

Du stehst nicht auf der Gästeliste.

Habe mein Problem behoben.
Ich habe versucht, auf localhost:3000 von meiner Vue-App auf localhost:8080 auf meine Express-API zuzugreifen, erhielt aber einen Fehler zurück.
Es stellte sich heraus, dass Sie http:// hinzufügen müssen, damit es funktioniert.
Verwenden Sie also http://localhost:3000 anstelle von localhost:3000 wenn Sie Entwicklertests durchführen.

Ich hatte das gleiche Problem mit der Wikimedia-API. Auf der CORS-Seite (https://www.mediawiki.org/wiki/Manual:$wgCrossSiteAJAXdomains) habe ich origin=* zur Anfrage hinzugefügt und das Problem behoben.

axios.get('https://en.wikipedia.org/w/api.php?action=opensearch&format=json&origin=*&search=Albert') .then(function(res) { console.log(res); }) .catch(function(err) { console.log('Error: =>' + err); })

Obwohl ich die gruselige Cors-Fehlermeldung erhalten habe, erreichte meine Anfrage den Server.

XMLHttpRequest cannot load "...url here...". No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.

Axios-Team, können Sie das bitte beheben???

@mellogarrett Dies ist kein Axios-bezogenes Problem. Lesen Sie dies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Wichtiges Zitat:

"Aus Sicherheitsgründen beschränken Browser ursprungsübergreifende HTTP-Anfragen, die von Skripten aus initiiert werden. XMLHttpRequest und Fetch folgen beispielsweise der Richtlinie für denselben Ursprung. Eine Webanwendung, die XMLHttpRequest oder Fetch verwendet, kann also nur HTTP-Anfragen an ihre eigene Domäne senden. To Webanwendungen zu verbessern, baten die Entwickler die Browseranbieter, domänenübergreifende Anfragen zuzulassen."

Bei vielen von denen, die dieses Problem haben, reagiert der Server wahrscheinlich nicht auf die OPTIONS-Anforderung. Stellen Sie sicher, dass Sie über Handler (mit CORS-Headern) sowohl für OPTIONS- als auch für POST-Anfragen verfügen. Der Client (axios) pingt zuerst OPTIONS und führt dann den POST aus.

Ich habe den gleichen Fehler bei Firefox, aber nicht bei Chromium. Dann erinnerte ich mich daran, dass NoScript (in Firefox) da war und die Anfrage an den Remote-Server verhinderte. Falls Sie NoScript (oder ein ähnliches Plugin) installiert haben, überprüfen Sie dies zuerst.
In meinem Fall hatte das Problem nichts mit Axios zu tun. Danke für die tolle Arbeit.

Für alle anderen, die nach einer Lösung für dieses Problem googeln, hatte ich dieselben Symptome, konnte das Problem jedoch auf eine php.ini-Einstellung auf dem Server zurückführen.

Meine Preflight-OPTIONS-Anfrage war erfolgreich und wurde von einer richtigen POST-Anfrage gefolgt, aber ich erhielt immer noch No 'Access-Control-Allow-Origin' header is present on the requested resource... ähnlich wie @mellogarrett . Das schien total seltsam, also habe ich ein Chrome-Plugin verwendet , um den CORS-Schutz vorübergehend zu deaktivieren. Danach konnte ich sehen, dass das Problem tatsächlich ein PHP-Fehler war:

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0

Dieser Beitrag enthält weitere Informationen zu dem Problem, aber kurz gesagt, wenn Sie PHP 5.6 verwenden, sollten Sie always_populate_raw_post_data in Ihrer php.ini auskommentieren und auf -1 . Hoffe das spart jemand anderem ein paar Stunden Fehlersuche 🤓

Hey @daltonamitchell Es scheint, als hätte ich das gleiche Problem (die Bedingungen deuten darauf hin, dass es sich um das gleiche Problem handelt). Aber ich frage mich: Wie haben Sie herausgefunden, dass der Rohdatenfehler das Problem war? Wenn Sie das von Ihnen erwähnte Chrome-Plugin verwenden, wird die CORS-Anfrage ausgeführt und alles funktioniert einwandfrei. Aber obwohl die Header richtig eingestellt sind, kann ich es ohne das Plugin nicht zum Laufen bringen. Vielleicht wird die Einstellungsmeldung einfach nicht angezeigt, aber das Problem besteht möglicherweise immer noch ...? Können Sie einen Rat geben, wie Sie das überprüfen können?

@RT-TL Das Plugin wird nur verwendet, um den Antwortinhalt anzuzeigen, ohne dass CORS ihn blockiert. In meinem Fall habe ich zu Testzwecken nur eine Zeichenfolge wie Hello World Nachdem ich CORS deaktiviert hatte, sah ich etwas wie

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will be removed in a future version. To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead. in Unknown on line 0
Hello World

Stellen Sie sicher, dass PHP-Warnungen aktiviert sind, indem Sie am Anfang Ihrer Controller-Methode error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE) oder error_reporting(E_ALL) hinzufügen. Wenn Sie immer noch nichts sehen, würde ich einfach versuchen, eine einfache JSON-Antwort zurückzugeben, um zu überprüfen, ob sie wie erwartet aussieht.

Hat jemand noch dieses Problem? Ich laufe in das gleiche:

const instance = axios.create({
    baseURL: 'http://localhost/',
    responseType: 'json',
    headers: {
        'Accept': 'application/json',
        'Content-Type': 'application/json',
        'Authorization': 'test',
        'X-Test': 'testing'
    }
})
axios.get('v2/portal/bar/foo?')

Antwortheader

HTTP/1.1 401 Unauthorized
Server: nginx/1.11.10
Date: Fri, 24 Mar 2017 07:12:13 GMT
Content-Type: application/json; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: *

Anfrage-Header

OPTIONS /v2/portal/bar/foo? HTTP/1.1
Host: localhost
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Access-Control-Request-Headers: authorization,content-type,x-test
Accept: */*
Referer: http://localhost:3000/dashboard/report
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8,fr;q=0.6,nl;q=0.4,zh-TW;q=0.2,zh;q=0.2,zh-CN;q=0.2

Ich kann nicht herausfinden, warum keiner meiner Header richtig gesendet wird.

Das gleiche Problem hier, die OPTIONS-Anfrage wird gestellt, die POST-Anfrage jedoch nicht.

TLDR: Abrufen funktioniert, Axios nicht, es sei denn, ich verwende JSON.stingify

Ich habe also auch die Variante dieses Fehlers gesehen, bei der OPTIONS 200 mit den Headern für Cross-Origin-Requests zurückgibt, aber kein POST erfolgt. Ich verwende diese Erweiterung und sie funktioniert wie erwartet. Aber ich bin mir ziemlich sicher, dass hier irgendein Problem vorliegt. Schauen Sie sich meine Anfrage an:

Mein Server antwortet mit Access-Control-Allow-Origin: *
Hier sind alle Beispiele mit Code und Screenshots:

Axios:

axios.post('http://localhost:3001/card', { test: 'test' })

bringen:

    return fetch('http://localhost:3001/card', {
      method: 'POST',
      body: { test: 'test' },
    })

mit JSON.stringify

    return fetch('http://localhost:3001/card', {
      method: 'POST',
      body: JSON.stringify({ test: 'test' }),
    })

Ich konnte Axios zum Laufen bringen, indem ich JSON.stringify meine Daten wie folgte:

    return axios.post('http://localhost:3001/card', JSON.stringify({ test: 'test' }));

Ich hatte das gleiche Problem wie @kwhitaker erklärte, Axios hat mein Cookie nicht richtig @zlyi vorgeschlagen hat, habe ich einfach die Zeile axios.defaults.withCredentials = true; hinzugefügt und alles hat wie erwartet funktioniert.

Habe alles probiert und habe immer noch das Problem. :(

Habe alles probiert und habe immer noch das Problem. :(

haben das Problem gelöst, indem Sie Folgendes zu .htaccess hinzugefügt haben:

<IfModule mod_headers.c> 
Header add Access-Control-Allow-Headers "origin, x-requested-with, content-type" 
Header add Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS" 
</IfModule>

Ich konnte dies mit einem Proxy beheben. Fügen Sie den Proxy zu package.json

{
    "proxy": "http://some-url/some-endpoint"
}

Dann fordern Sie an:

axios.get('/user?ID=12345')
  .then(function (response) {
    console.log(response)
  })
  .catch(function (error) {
    console.log(error)
  })

Dies ist ein serverseitiges Problem, es muss 'Acces-Control-Allow-Origin': '*' in Ihrem Antwortheader enthalten sein. Wenn Sie Express verwenden, können Sie npm-cors für eine robustere/elegantere Implementierung verwenden.

+1 @ProfNandaa
Ich habe einen Export auf meinem lokalen Server erstellt

# cors.js file
module.exports = (req, res, next) => {
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept");
  next();
}

Also weise ich zu:
```
const cors = require('cors');
router.use(cors);
````
jetzt mach weiter... danke

Der Fehler tritt auf, wenn der Server die OPTION-Anforderung nicht akzeptiert.

Für diejenigen, die sagen "Fügen Sie die OPTION-Anforderungsbehandlung zu Ihrem Server hinzu", funktioniert dies nicht. Ich betreibe eine lokale Umgebung, in der die OPTION-Anforderungsbehandlung aktiviert ist.

Ich habe dieses Problem genauso erlebt wie ein Benutzer oben, wo Axios.post(url, obj) den CORS 403-Fehler zurückgegeben hat, aber das Aktualisieren auf Axios.post(url, JSON.stringify(obj)) funktionierte korrekt.

Ich arbeite nur an einem einfachen Tutorial-Projekt und hatte Probleme beim Zugriff auf verschiedene APIs. Die einzige Lösung, die ich gefunden habe, ist die von Thiagodebastos oben erwähnte.

Ich habe einfach jsonp durch get ersetzt und konnte auf die Daten zugreifen.

Ich hatte dieses Problem und koa-cors war eine einfache Lösung! (npm-cors für Express-Benutzer nach ProfNandaa)

Für diejenigen, die immer noch Probleme damit haben: Axios funktioniert gut mit CORs , mit OPTIONS-Anfragen, mit JSON, das als Hauptteil der Anfrage gesendet wird, ohne JSON.encoded , und mit Cookies, die ordnungsgemäß gesendet und beibehalten werden, solange Axios und der Server, der auf die Anfragen reagiert, richtig konfiguriert ist.

Es dauerte einige frustrierende Versuch und Irrtum, aber wir haben domänenübergreifende Anfragen, die mit Axios gut funktionieren.

Ein paar Punkte:

Damit die Anfrage funktioniert, stellen Sie sicher, dass

• Der Server antwortet auf OPTIONS-Anfragen, als ob die Antwort etwas anderes als 200 mit allen korrekten Headern ist, werden "preflighted"-Anfragen fehlschlagen.

• Die Anfrage erfolgt mit den richtigen Headern und der Server antwortet mit allen erforderlichen Headern.

• Wenn Cookies/Autorisierungsheader oder TLS-Clientzertifikate erforderlich sind, senden Sie allowCredentials für die Axios-Anforderung auf true. Dies kann standardmäßig ( axios.defaults.withCredentials = true ) oder per Anfrage erfolgen.

Beispiel für erfolgreiche Anforderungsheader

Access-Control-Request-Headers: Content-Type
Access-Control-Request-Method: GET

Beispiel für erfolgreiche Antwortheader

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
Access-Control-Allow-Origin: http://your-origin-url.com

Wir haben nach und nach Antwortheader hinzugefügt und festgestellt, dass wir verschiedene, schwer zu diagnostizierende Fehler und unerwartetes Verhalten mit verschiedenen Kombinationen hatten

Ohne Access-Control-Allow-Credentials: true Cookies nicht gesendet oder beibehalten, was nach dem Lesen der MDN-Seite für diesen Header sinnvoll ist

Das Durchlesen dieser Dokumentation hilft.

Jeder, der das Problem hat, ...Allow-Headers: Content-Type ist wichtig.

Access-Control-Allow-Origin: '*'
Access-Control-Allow-Methods: ...
Access-Control-Allow-Headers: Content-Type, Accept

Ich verwende diese Chrome-Erweiterung namens 'Allow-Control-Allow-Origin: *'
hoffe es konnte deinem Problem helfen.

Für alle, die nicht verstehen, warum Axios diesen Fehler NICHT beheben kann:

Dies ist kein Axios-Problem. Es ist ein Problem mit dem Browser. JS im Browser lehnt Anfragen an Server ab, für die nicht die richtigen Header festgelegt sind. Wenn Sie dies mit etwas wie React auf dem Client verwenden, lassen Sie sich nicht verwirren, dies ist kein React- oder Axios-Problem, es ist einfach der Browser, der den CORS-Standard respektiert.

JakeElder gibt hier eine gute Beschreibung, was Sie auf der Serverseite Ihrer API tun müssen: https://github.com/mzabriskie/axios/issues/191#issuecomment -311069164

Wenn Sie keine Kontrolle über den Server haben, auf den Sie zugreifen möchten, sollten Sie einen Proxyserver erstellen, der den Inhalt für Sie abruft und mit den richtigen Headern zurückgibt.

Nicht sicher, warum dies implementiert wurde. Es ist sicherlich ärgerlich, wenn Sie nur eine Anfrage an einen Server stellen möchten, um Informationen zu erhalten, dies jedoch nicht möglich ist, da der Server keinen bestimmten Headersatz hat. Scheint extrem restriktiv zu sein. Naja ...

@robins-eldo Auch hier glaube ich nicht, dass Sie Recht haben.

Mein ursprünglicher Kommentar:

For those commenting saying "Add OPTION request handling to your server", that does not work. I'm running a local environment that has OPTION request handling enabled.

I experienced this issue identically as a user above, where Axios.post(url, obj) returned the CORS 403 forbidden error, but updating that to Axios.post(url, JSON.stringify(obj)) worked correctly.

Wenn es sich tatsächlich um ein Serverproblem und nicht um ein Axios-Problem gehandelt hätte, hätte das Stringifizieren eines Objekts keine Auswirkung gehabt, da die OPTIONS-Anfrage so oder so fehlgeschlagen wäre.

@alexanderbanks

Ich bin mir bei der HTTP-Methode OPTION nicht sicher, aber mein spezifisches Problem war, dass ein React-Client versucht, an eine von mir geschriebene interne API POST zu senden (die interne API ist hier der Server). Ich bekomme immer diese Fehlermeldung: Failed to load resource: Origin http://localhost:7149 is not allowed by Access-Control-Allow-Origin. XMLHttpRequest cannot load http://localhost:8902/user-login due to access control checks.

Ich dachte, es könnte ein Axios-Problem sein, also habe ich stattdessen Unirest ausprobiert und immer wieder den gleichen Fehler erhalten. Also dachte ich mir, es muss etwas anderes sein. Ich bin mir nicht sicher, ob dies ein Browserproblem oder React ist, aber sobald ich meinem API-Server (der eine Nodejs + Express-API ist) Folgendes hinzugefügt hatte, funktionierte alles mit Axios und Unirest auf der Clientseite:

app.use(function(req, res, next) { res.header("Access-Control-Allow-Origin", "*"); next(); });

Vielleicht ist mein Verständnis von dem, was hier hinter den Kulissen passiert, etwas eingeschränkt, aber dieser Code auf dem Server hat das Problem für mich gelöst.

Stellen Sie sicher, dass Ihr Server den Ursprungszugriff nicht zu stark einschränkt, und wenn Sie Lust haben, No-Cors zu umgehen, versuchen Sie Folgendes:

    return axios(url, {
      method: 'POST',
      mode: 'no-cors',
      headers: {
        Accept: 'application/json',
        'Content-Type': 'application/json',
      },
      withCredentials: true,
      credentials: 'same-origin',
    }).then(response => {
    })

Ich denke, einige Leute hier sind verwirrt darüber, wie CORS funktioniert. Bei dem ursprünglichen Problem ging es jedoch nicht um CORS, oder zumindest sollte das das wichtige Problem sein. Ich meine, wenn Sie CORS richtig konfiguriert haben, aber auch die Post nicht funktioniert, dann ist das ein Problem zu melden, nicht wie man einen Server richtig konfiguriert

API verhält sich komisch. Alle Cors GET-Anfragen funktionierten mit "credentials: true".
Für POST-Anforderungen funktioniert dieselbe Ursprungsanforderung ohne Stringify-Datenobjekt, während für CORS-POST-Anfragen auch mit der Arbeit beginnen, wenn ich das Datenobjekt stringify.

Habe nicht genau den Grund verstanden, aber Problem für mich gelöst.

Es tut mir leid, aber ich schließe diesen Thread, da es so aussieht, als würden wir uns um das gleiche Thema drehen. Wenn Sie ein bestimmtes Problem haben, das nicht in einem anderen Problem behandelt wurde (allgemeine CORS-Probleme aufgrund von Fehlkonfigurationen, POST-Anfragen werden als JSON statt form-urlencoded gesendet usw.), öffnen Sie bitte ein neues mit spezifischen Details.