Axios: impossible de faire fonctionner le POST intersite

De plus, je mets également withCredentials sur true dans le fichier config.

Je viens également de rencontrer ce problème et cela ne semble se produire que pour moi sur Mac. J'ai passé 3 jours et 3 bonnes nuits à essayer de déboguer mon réseau et j'ai décidé sur un coup de tête d'essayer cela en utilisant une requête XHR vanille et j'ai réalisé que le problème n'était pas mon réseau, mais axios.

Moi aussi, je fais des demandes intersites avec des informations d'identification définies sur true. En regardant la demande de réseau, vous obtenez un ERR_EMPTY_RESPONSE et c'est comme si la demande avait échoué avant même de quitter le navigateur.

Voici ma config :

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

Si j'en ai l'occasion, j'essaierai d'approfondir la question.

Oh bon je ne suis pas fou. :) S'il vous plaît examiner cela si possible.

Il s'avère que mon problème n'était pas lié à Axios. Cisco Anyconnect bloquait les demandes d'options de ma machine... pour des raisons ?

Les requêtes inter-domaines ne nécessitent aucune configuration supplémentaire. Il reviendra à l'utilisation de XDomainRequest pour l'ancien IE. https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js#L22

Pouvez-vous fournir plus de détails? Quel navigateur, système d'exploitation, version d'axios, éventuels messages d'erreur.

Je ne peux pas parler pour Jenny, mais quelque chose en particulier que cette bibliothèque fait provoque le blocage des demandes par la sécurité par défaut de Cisco Anyconnect, ce qui signifie qu'il est possible que d'autres paramètres de sécurité le fassent également. J'essaye de retrouver ça mais pas de chance pour l'instant.

Cela peut être reproduit en effectuant une demande intersites sur un mac installé avec Cisco Anyconnect et éventuellement d'autres clients VPN.

Mon environnement est :

• Axio 0.8.1
• El Capitan
• Chrome
• Message d'erreur : "Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. L'origine ' http://localhost :3000' n'est donc pas autorisée à accéder."

Notez que la même requête fonctionne avec curl.

Merci d'avoir étudié cela !

Avec CORS, une demande de contrôle en amont est effectuée auprès du serveur pour voir si la demande est autorisée. Vous devrez faire en sorte que votre serveur réponde aux requêtes qui ont OPTIONS comme méthode de requête en définissant l'en-tête Acces-Control-Allow-Origin: * qui autorisera les requêtes de n'importe quelle origine. Alternativement, vous pouvez autoriser uniquement certaines origines Acces-Control-Allow-Origin: http://example.com .

Oui, je comprends ça. Mais le serveur n'est pas à moi. J'utilise un Baas (backend-as-a-service). Et ils ont déjà ajouté mon domaine à la liste autorisée. J'ai vérifié que d'autres personnes utilisant ledit Baas n'ont pas eu de tels problèmes.

Je ne fais que supprimer le message d'erreur que vous avez fourni, mais sur cette base, il ne semble pas que vous ayez des choses qui fonctionnent pour vous. L'utilisation de curl n'échouerait pas car la sécurité d'origine croisée n'est qu'une limitation dans le navigateur.

Pouvez-vous ouvrir l'onglet réseau dans votre navigateur et partager ce que vous obtenez en réponse à la demande OPTIONS ? Espérons que voir les données de réponse et les en-têtes aidera à déboguer ce problème.

Merci

Voici les en-têtes :

Voici les en-têtes de réponse de GitHub lorsque j'utilise axios pour obtenir mon profil utilisateur à partir de leur API :

Vous pouvez voir que GitHub ajoute le Access-Control-Allow-Origin: * . Il manque des en-têtes de type Access-Control réponse de votre Baas.

Je vois je vois hmm. Désolé pour la réponse super tardive. Permettez-moi d'examiner cela un peu plus. Merci beaucoup.

Je ne sais pas si ce que je vois est lié ou non. Fondamentalement, je peux envoyer une demande d'authentification à notre serveur distant et récupérer un cookie, mais les appels ultérieurs au serveur n'envoient pas les cookies avec eux, ce qui entraîne une erreur.

Voici les en-têtes de l'appel POST pour vous connecter :

Et maintenant, un appel GET suivi :

L'adresse IP répertoriée sous origin est la mienne, donc cela ne devrait pas être un problème. Si ce n'est pas le bon endroit pour cela, je suis heureux de créer un nouveau numéro ou de le joindre à celui existant approprié.

Comme une nouvelle ride ; J'ai testé un appel de suivi GET utilisant uniquement le XHR direct, et le cookie est bien envoyé. Faire le même appel via Axios, cependant, entraîne le même problème que j'ai mentionné ci-dessus.

Pouah. S'il vous plaît ne pas tenir compte - je n'envoyais pas les choses comme prévu via Axios :)

Je suis également confronté au même problème.
OPTIONS L'appel passe, mais les appels POST restent bloqués dans les cors.
http://stackoverflow.com/questions/36907693/axios-cors-issue-with-github-oauth-not-getting-access-token

Comment un problème aussi ÉNORME n'est-il pas traité ?

+1

+1

+1

+1

+1

+1

+1

@dsacramone quel est le problème que vous voyez ? Il semble que la plupart des problèmes signalés soient des problèmes de serveur ou de fausses alarmes. S'il y a une erreur reproductible que je peux regarder, je suis heureux de travailler sur un correctif.

obtenir ça aussi

XMLHttpRequest ne peut pas charger https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish. Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. L'origine ' http://localhost :3000' n'est donc pas autorisée à accéder.

l'obtenir également en utilisant fetch pour noter. Je pense que son chrome a récemment rendu sa politique de définition de requête plus stricte, je pense qu'il aura besoin d'une sorte d'en-tête (je ne sais pas quoi).

voici un exemple (tous deux servis via https)

Exemple 1 - Fonctionne bien

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

Exemple 2 - Ne fonctionne pas - affichage d'une erreur ?

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

voici la réponse d'erreur

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

quelque chose qui pourrait être pertinent se trouve dans transformResponse ? Je me demande ce que signifie le bit PROTECTION_PREFIX ?

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

même essayer

mode : 'pas de cors'
in fetch donne toujours cette erreur

Je suis sûr que les réponses sont assez simples et ont juste besoin d'une sorte d'en-tête, je ne sais pas quoi, va continuer à jouer.

l'api wikipedia pourrait être juste un exemple bancal, même erreur sur d'autres ?

Je supprime ce code, peut fonctionner : axios.defaults.withCredentials = true

J'ai obtenu que l'API wikipedia fonctionne correctement avec

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

Aucune configuration supplémentaire requise.

Obtenir la même erreur avec axios. Voici mon composant React :

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

_Remarque : Je peux parfaitement accéder à l'API avec la requête Node._

Je rencontre la même erreur que @Sinistralis . Sur la dernière version de chrome dans Mac OSX, je reçois net::ERR_EMPTY_RESPONSE sur les requêtes CORS qui sont faites correctement (mon serveur gère très bien tous les en-têtes CORS, y compris OPTIONS). C'est étrange car sur Safari iOS10, exactement le même code fonctionne sans problème. Je vais essayer d'enquêter un peu plus par moi-même pour voir comment cela pourrait être résolu.

Sur un ancien mac (10.11) avec la dernière version de chrome, je ne peux pas reproduire cette erreur avec exactement le même code. C'est vraiment très étrange. Vous pourrez peut-être reproduire en visitant cette application très simple : http://lights.suyashkumar.com et en inspectant la console (le code est ici . Sur certaines machines, il n'y aura pas d'erreur et cela vous redirigera vers la connexion. Sur d'autres il ne redirigera pas et vous laissera sur la page principale.

Résolu mon erreur. Pour moi, c'était un problème d'affecter un en-tête dans config.headers avec une valeur nulle au démarrage de l'application (il extrait une valeur du stockage local, et au départ, il n'y a rien). L'affectation de la valeur à une chaîne vide lorsque la valeur est nulle résout le problème. Je me demande si c'est quelque chose qui peut ou devrait être géré dans axios (je ne sais pas s'il est utile de passer des en-têtes nuls à xhr s'il se casse _parfois_).

Pour d'autres avec un problème similaire, j'ai trouvé que certains clients VPN peuvent également bloquer les requêtes OPTIONS (voir ici )

L'erreur CORS trompeuse est toujours dans axios. Le polyfill fetch prend en charge mode: 'no-cors' pour résoudre ce problème.

Nous devons faire ce genre de requêtes pour faire des requêtes contre des machines dans d'autres environnements que nous opérons, ainsi que sur la même machine sur des ports différents !

@dreki Veuillez fournir la description du problème que vous avez mentionné.

Vous ne pouvez rien faire du côté client, lorsque le serveur n'accepte tout simplement pas les demandes de votre origine. Si vous pouviez, nous aurions une énorme fuite de sécurité ici (et avec "nous" je veux dire tout Internet)...

Je pense qu'axios agit et réagit de manière totalement conforme ici.

L'en-tête de réponse important est Access-Control-Allow-Origin qui définit essentiellement les origines valides, qui sont autorisées à appeler ce service côté serveur. Si votre client n'appelle depuis aucune de ces origines configurées, la demande sera refusée avec une erreur de console comme celle-ci :

XMLHttpRequest ne peut pas charger http://localhost :8080/v1/api/search?q=candles. Aucun en-tête 'Access-Control-Allow-Origin' n'est présent sur la ressource demandée. L'origine ' http://localhost :9999' n'est donc pas autorisée à accéder.

Vous n'êtes pas sur la liste des invités.

Correction de mon problème.
J'essayais d'accéder à mon api express sur localhost:3000 partir de mon application vue sur localhost:8080 , mais une erreur s'est produite.
Il s'avère que vous devez ajouter http:// pour que cela fonctionne.
Utilisez donc http://localhost:3000 au lieu de localhost:3000 lors des tests de développement.

J'ai eu le même problème avec wikmedia api. en consultant leur page CORS (https://www.mediawiki.org/wiki/Manual:$wgCrossSiteAJAXdomains), j'ai ajouté origin=* à la demande et cela a résolu le problème.

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

Même si j'ai reçu le message d'erreur cors effrayant, ma demande touchait le serveur.

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.

Equipe Axios, pouvez-vous corriger s'il vous plait ???

@mellogarrett Ce n'est pas un problème lié à axios. Lisez ceci : https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Citation importante :

"Pour des raisons de sécurité, les navigateurs restreignent les requêtes HTTP d'origine croisée lancées à partir de scripts. Par exemple, XMLHttpRequest et Fetch suivent la politique de même origine. Ainsi, une application Web utilisant XMLHttpRequest ou Fetch ne peut faire des requêtes HTTP que vers son propre domaine. Pour améliorer les applications Web, les développeurs ont demandé aux fournisseurs de navigateurs d'autoriser les requêtes inter-domaines."

Beaucoup de ceux qui ont ce problème n'ont probablement pas le serveur répondant à la requête OPTIONS. Assurez-vous d'avoir des gestionnaires (avec des en-têtes CORS) pour les requêtes OPTIONS et POST. Le client (axios) va d'abord envoyer un ping à OPTIONS, puis effectuer le POST.

J'ai la même erreur sur Firefox, mais pas sur Chromium. Ensuite, je me suis souvenu que NoScript était là (dans Firefox) empêchant la demande au serveur distant. Si NoScript (ou un plugin similaire) est installé, vérifiez-le d'abord.
Dans mon cas, le problème n'était pas lié à Axios. Merci pour le bon travail.

Pour quiconque cherchait une solution à ce problème sur Google, j'avais tous les mêmes symptômes, mais j'ai tracé le problème à un paramètre php.ini sur le serveur.

Ma demande OPTIONS de contrôle en amont a réussi et suivie d'une demande POST appropriée, mais j'obtenais toujours No 'Access-Control-Allow-Origin' header is present on the requested resource... similaire à @mellogarrett . Cela semblait totalement étrange, j'ai donc utilisé un plugin Chrome pour désactiver temporairement la protection CORS. Après cela, j'ai pu voir que le problème était en fait une erreur PHP :

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

Cet article contient plus d'informations sur le problème, mais en bref, si vous utilisez PHP 5.6, vous devez décommenter always_populate_raw_post_data dans votre php.ini et définir sur -1 . J'espère que cela permettra à quelqu'un d'autre d'économiser quelques heures de dépannage 🤓

Hé @daltonamitchell Il semble que j'ai le même problème (les conditions suggèrent qu'il s'agit du même problème). Mais je me demande : comment avez-vous compris que l'erreur de données brutes de publication était le problème ? Lorsque vous utilisez le plugin chrome que vous avez mentionné, la requête CORS passe et tout fonctionne bien. Mais même si les en-têtes sont correctement définis, je ne peux pas le faire fonctionner sans le plugin. Alors peut-être que le message d'obsolescence ne s'affiche tout simplement pas, mais le problème est peut-être toujours là... ? Pouvez-vous donner des conseils pour vérifier cela?

@RT-TL le plugin est uniquement utilisé pour voir le contenu de la réponse sans que CORS le bloque. Dans mon cas, à des fins de test, je renvoyais simplement une chaîne comme Hello World donc une fois que j'ai désactivé CORS, j'ai vu quelque chose comme

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

Assurez-vous que les avertissements PHP sont activés en ajoutant error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE) ou error_reporting(E_ALL) en haut de votre méthode de contrôleur. Si vous ne voyez toujours rien, j'essaierais simplement de renvoyer une simple réponse JSON pour vérifier qu'elles ont l'air comme prévu.

Est-ce que quelqu'un rencontre toujours ce problème ? Je rencontre le même :

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?')

En-têtes de réponse

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

En-têtes de requête

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

Je ne peux pas comprendre pourquoi aucun de mes en-têtes n'est envoyé correctement.

Même problème ici, la demande OPTIONS est faite, mais la demande POST ne l'est pas.

TLDR : l'extraction fonctionne, axios ne fonctionne pas à moins que j'utilise JSON.stingify

J'ai donc également vu la variante de cette erreur où OPTIONS renvoie 200 avec les en-têtes définis pour les demandes d'origine croisée, mais aucun POST n'est effectué. J'utilise cette extension et elle commence à fonctionner comme prévu. Mais je suis presque sûr qu'il y a une sorte de problème ici. Jetez un oeil à ma demande:

Mon serveur répond avec Access-Control-Allow-Origin: *
Voici tous les exemples avec code et captures d'écran :

Axes :

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

aller chercher:

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

avec JSON.stringify

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

J'ai pu faire fonctionner axios en JSON.stringify -ing mes données comme ceci :

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

J'étais confronté au même problème que @kwhitaker expliqué, axios n'envoyait pas mon cookie correctement, ce qui entraînait des réponses avec moins d'informations (je suppose en raison de problèmes de sécurité). D'un autre côté, la demande XHR régulière a bien fonctionné. Ensuite, comme @zlyi l'a suggéré, je viens d'ajouter la ligne axios.defaults.withCredentials = true; et tout a commencé comme prévu.

J'ai tout essayé et toujours le problème. :(

J'ai tout essayé et toujours le problème. :(

ont géré le problème en ajoutant ce qui suit à .htaccsess :

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

J'ai pu résoudre ce problème en utilisant un proxy. Ajouter le proxy au package.json

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

Ensuite, demandez :

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

Il s'agit d'un problème côté serveur, vous devez avoir 'Acces-Control-Allow-Origin': '*' dans votre en-tête de réponse. Si vous utilisez Express, vous pouvez utiliser npm-cors pour une implémentation plus robuste/élégante.

+1 @ProfNandaa
j'ai créé une exportation sur mon serveur local

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

alors j'assigne :
```
const cors = require('cors');
router.use(cors);
````
maintenant vas-y... merci

L'erreur se produira lorsque le serveur n'accepte pas la demande OPTION.

Pour ceux qui commentent "Ajouter la gestion des requêtes OPTION à votre serveur", cela ne fonctionne pas. J'exécute un environnement local dans lequel la gestion des demandes OPTION est activée.

J'ai rencontré ce problème de la même manière qu'un utilisateur ci-dessus, où Axios.post(url, obj) renvoyé l'erreur interdite CORS 403, mais la mise à jour vers Axios.post(url, JSON.stringify(obj)) fonctionné correctement.

Je travaille sur un simple projet de tutoriel et j'ai eu du mal à accéder à diverses API. La seule solution que j'ai trouvée pour fonctionner est celle mentionnée par thiagodebastos ci-dessus.

J'ai simplement remplacé jsonp par get et j'ai pu accéder aux données.

J'ai eu ce problème et koa-cors était une solution simple ! (npm-cors pour les utilisateurs Express selon ProfNandaa)

Pour ceux qui ont encore des problèmes avec cela : Axios fonctionnera correctement avec les CORs , avec les requêtes OPTIONS, avec JSON envoyé comme corps de la requête sans être JSON.encoded , et avec les cookies envoyés et persistés correctement, tant qu'Axios et le serveur répondant aux requêtes est configuré correctement.

Cela a pris quelques essais et erreurs frustrants, mais nous avons des demandes inter-domaines qui fonctionnent bien avec Axios.

Quelques points:

Pour que la demande fonctionne, assurez-vous

• Le serveur répond aux requêtes OPTIONS, comme si la réponse était autre que 200 avec tous les en-têtes corrects définis, les requêtes « contrôlées en amont » échoueront.

• La demande est faite avec les en-têtes corrects et le serveur répond avec tous les en-têtes nécessaires.

• Si des cookies/en-têtes d'autorisation ou des certificats client TLS sont requis, envoyez allowCredentials à true pour la requête Axios. Cela peut être fait par défaut ( axios.defaults.withCredentials = true ) ou par requête.

Exemple d'en-têtes de requêtes réussies

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

Exemple d'en-têtes de réponse réussie

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

Nous avons progressivement ajouté des en-têtes de réponse et constaté que nous avions diverses erreurs difficiles à diagnostiquer et des comportements inattendus avec différentes combinaisons

Sans Access-Control-Allow-Credentials: true cookies n'étaient pas envoyés ou conservés, ce qui est logique après avoir lu la page MDN pour cet en-tête

La lecture de cette documentation est utile.

Toute personne ayant le problème, ...Allow-Headers: Content-Type est important.

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

J'utilise cette extension chrome nommée 'Allow-Control-Allow-Origin: *'
J'espère que cela pourrait aider votre problème.

Pour tous ceux qui ne comprennent pas pourquoi Axios NE PEUT PAS corriger cette erreur :

Ce n'est pas un problème Axios. C'est un problème avec le navigateur. JS dans le navigateur rejettera les demandes aux serveurs qui n'ont pas les en-têtes appropriés définis. Si vous l'utilisez avec quelque chose comme React sur le client, ne vous y trompez pas, ce n'est pas un problème React ou Axios, c'est simplement le navigateur respectant la norme CORS.

JakeElder donne une bonne description de ce que vous devez faire côté serveur de votre API ici : https://github.com/mzabriskie/axios/issues/191#issuecomment -311069164

Si vous n'avez aucun contrôle sur le serveur auquel vous essayez d'accéder, vous devez créer un serveur proxy pour récupérer le contenu pour vous et le renvoyer avec les en-têtes corrects.

Je ne sais pas pourquoi cela a été mis en œuvre. C'est certainement ennuyeux lorsque vous voulez juste faire une demande à un serveur pour obtenir des informations mais que vous ne pouvez pas parce que le serveur n'a pas d'en-tête spécifique. Cela semble extrêmement restrictif. Tant pis ...

@robins-eldo Encore une fois, je ne pense pas que vous ayez raison.

Mon commentaire initial :

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.

S'il s'agissait en fait d'un problème de serveur, et non d'un problème Axios, la chaîne d'un objet n'aurait eu aucun effet, car la requête OPTIONS aurait échoué de toute façon.

@alexanderbanks

Je ne suis pas sûr de la méthode HTTP OPTION, mais mon problème spécifique était que j'avais un client React essayant de POST sur une API interne que j'avais écrite (l'API interne étant le serveur ici). J'ai continué à recevoir cette erreur : 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.

J'ai pensé qu'il s'agissait peut-être d'un problème Axios, j'ai donc essayé Unirest à la place et j'ai continué à obtenir la même erreur. Alors je me suis dit que ça devait être autre chose. Je ne sais pas s'il s'agit d'un problème de navigateur ou de React, mais dès que j'ai ajouté ce qui suit à mon serveur d'API (qui est une API Nodejs + Express), tout a commencé à fonctionner avec Axios et Unirest côté client :

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

Peut-être que ma compréhension de ce qui se passe réellement dans les coulisses ici est quelque peu limitée, cependant, ce morceau de code sur le serveur a résolu le problème pour moi.

Assurez-vous que votre serveur ne restreint pas trop l'accès à l'origine et si vous avez envie de contourner les non-cors, essayez ceci :

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

Je pense qu'il y a des gens ici qui ne savent pas comment fonctionne la SCRO. Cependant, le problème initial ne concernait pas le CORS, ou du moins cela devrait être le problème important. Je veux dire, lorsque vous avez correctement configuré CORS mais même si la publication ne fonctionne pas, c'est un problème à signaler, pas comment configurer correctement un serveur

L'API agit bizarrement. Toutes les requêtes GET cors fonctionnaient avec « identifiants : vrai ».
Pour les demandes POST, la même demande d'origine fonctionne sans chaîner l'objet de données tandis que pour la demande CORS POST, elle commence également à fonctionner lorsque je chaîne l'objet de données.

Je n'ai pas compris exactement la raison mais le problème est résolu pour moi.

Je suis désolé mais je verrouille ce fil car il semble que nous faisons des cercles autour du même sujet. Si vous rencontrez un problème spécifique qui n'a pas été traité dans un autre numéro (problèmes CORS généraux dus à une mauvaise configuration, requêtes POST envoyées en tant que JSON au lieu de form-urlencoded, etc.), veuillez en ouvrir un nouveau avec des détails spécifiques.