Axios: não consigo fazer o POST cross-site funcionar

Além disso, também estou definindo withCredentials como true na configuração.

Eu também encontrei esse problema e isso só parece acontecer comigo no Mac. Passei uns bons 3 dias e noites tentando depurar minha rede e decidi por capricho tentar fazer isso usando uma solicitação XHR vanilla e percebi que o problema não era minha rede, mas axios.

Eu também estou fazendo solicitações entre sites com credenciais definidas como verdadeiras. Olhando para a solicitação de rede, você obtém um ERR_EMPTY_RESPONSE e é como se a solicitação falhou antes mesmo de sair do navegador.

Esta é minha configuração:

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

Se eu tiver uma chance, tentarei investigar isso mais detalhadamente.

Oh bom, eu não sou louco. :) Por favor, analise isso, se possível.

Acontece que meu problema não estava relacionado à Axios. Cisco Anyconnect estava bloqueando solicitações de opções de minha máquina ... por que motivos?

As solicitações de domínio cruzado não exigem nenhuma configuração extra. Ele voltará a usar XDomainRequest para o IE mais antigo. https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js#L22

Você pode fornecer mais detalhes? Qual navegador, sistema operacional, versão do axios, qualquer mensagem de erro.

Não posso falar por Jenny, mas algo em particular esta biblioteca faz com que as solicitações sejam bloqueadas pela segurança padrão do Cisco Anyconnect, o que significa que é possível que outras configurações de segurança façam isso também. Estou tentando rastrear isso, mas sem sorte até agora.

Isso pode ser reproduzido fazendo uma solicitação entre sites em um mac instalado com Cisco Anyconnect e possivelmente outros clientes VPN.

Meu ambiente é:

• Axios 0.8.1
• o capitão
• cromada
• Mensagem de erro: "Nenhum cabeçalho 'Access-Control-Allow-Origin' está presente no recurso solicitado. Portanto, o acesso de origem ' http: // localhost : 3000' não é permitido."

Observe que a mesma solicitação funciona com curl.

Obrigado por investigar isso!

Com o CORS, uma solicitação de comprovação é feita ao servidor para ver se a solicitação é permitida. Você precisará que seu servidor responda às solicitações que têm OPTIONS como método de solicitação, definindo o cabeçalho Acces-Control-Allow-Origin: * que permitirá solicitações de qualquer origem. Alternativamente, você pode permitir apenas certas origens Acces-Control-Allow-Origin: http://example.com .

Sim eu entendo isso. Mas o servidor não é meu. Estou usando um Baas (backend-as-a-service). E eles já adicionaram meu domínio à lista de permissões. Verifiquei se outras pessoas que usam os ditos Baas não tiveram esses problemas.

Estou apenas reproduzindo a mensagem de erro que você forneceu, mas, com base nisso, não parece que as coisas estão funcionando para você. Não falharia usando curl porque a segurança de origem cruzada é apenas uma limitação dentro do navegador.

Você pode abrir a guia de rede em seu navegador e compartilhar o que obtém como resposta à solicitação OPTIONS? Esperançosamente, ver os dados de resposta e cabeçalhos ajudará a depurar esse problema.

Obrigado

Aqui estão os cabeçalhos:

Aqui estão os cabeçalhos de resposta do GitHub quando eu uso axios para obter meu perfil de usuário de sua API:

Você pode ver que o GitHub adiciona Access-Control-Allow-Origin: * . A resposta do seu Baas não contém quaisquer cabeçalhos do tipo Access-Control .

Eu vejo, eu vejo hmm. Desculpe pela resposta tardia. Deixe-me examinar isso um pouco mais. Muito obrigado.

Não tenho certeza se o que estou vendo está relacionado ou não. Basicamente, posso enviar uma solicitação de autenticação ao nosso servidor remoto e obter um cookie, mas as chamadas subsequentes ao servidor _não_ enviam os cookies com eles, resultando em um erro.

Aqui estão os cabeçalhos da chamada POST para fazer login:

E agora uma chamada de acompanhamento GET :

O endereço IP listado em origin é meu, então isso não deve ser um problema. Se este for o lugar errado para isso, terei o prazer de fazer uma nova edição ou anexar ao existente apropriado.

Como uma nova ruga; Eu testei uma chamada de GET acompanhamento usando apenas XHR direto e o cookie foi enviado sem problemas. Fazer a mesma chamada por meio do Axios, no entanto, resulta no mesmo problema que mencionei acima.

ECA. Desconsidere - eu não estava enviando as coisas como esperado por meio do Axios :)

Eu também estou enfrentando o mesmo problema.
OPÇÕES A chamada continua, mas as chamadas POST ficam presas em cors.
http://stackoverflow.com/questions/36907693/axios-cors-issue-with-github-oauth-not-getting-access-token

Como um problema tão ENORME não é abordado?

+1

+1

+1

+1

+1

+1

+1

@dsacramone qual é o problema que você está vendo? Parece que a maioria dos problemas relatados são problemas com o servidor ou alarmes falsos. Se houver um erro reproduzível que eu possa verificar, ficarei feliz em trabalhar para corrigi-lo.

recebendo isso também

XMLHttpRequest não pode carregar https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish. Nenhum cabeçalho 'Access-Control-Allow-Origin' está presente no recurso solicitado. Portanto, o acesso de origem ' http: // localhost : 3000' não é permitido.

também obtê-lo usando fetch to note. Acho que o cromo recentemente tornou a política de configuração de solicitação mais rígida, acho que vai precisar de algum tipo de cabeçalho (não tenho certeza do quê).

aqui está algum exemplo (ambos servidos por https)

Exemplo 1 - Funciona bem

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

Exampel 2 - Não funciona - apresenta erro?

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

aqui está a resposta de erro

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

algo que pode ser relevante está no transformResponse? estou me perguntando o que significa o 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;
    }
}

mesmo tentando

modo: 'no-cors'
em buscar ainda dá esse erro

Tenho certeza de que as respostas são muito simples e só precisa de algum tipo de cabeçalho, mas não tenho certeza do que vai continuar brincando.

a API da Wikipedia pode ser apenas um exemplo instável, mesmo erro em outros?

Excluo este código, pode funcionar: axios.defaults.withCredentials = true

Consegui que a API da Wikipedia funcionasse bem com jsonp

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

Nenhuma configuração extra necessária.

Obtendo o mesmo erro com axios. Este é meu componente 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>
    )
  }
}

_Observação: posso acertar a API perfeitamente bem com a solicitação do Node._

Estou encontrando o mesmo erro de @Sinistralis . Na versão mais recente do Chrome no Mac OSX, estou recebendo net::ERR_EMPTY_RESPONSE em solicitações CORS feitas corretamente (meu servidor lida perfeitamente com todos os cabeçalhos CORS, incluindo OPÇÕES). É estranho porque no iOS10 safari, exatamente o mesmo código funciona sem problemas. Tentarei investigar um pouco mais por conta própria para ver como isso pode ser resolvido.

Em um mac mais antigo (10.11) com a versão mais recente do chrome, não posso reproduzir este erro exatamente com o mesmo código. Isso é realmente muito estranho. Você pode reproduzir visitando este aplicativo muito simples: http://lights.suyashkumar.com e inspecionando o console (o código está aqui . Em algumas máquinas, não haverá nenhum erro e ele irá redirecioná-lo para fazer o login. Em outras ele não redirecionará e o deixará na página principal.

Resolvido meu erro. Para mim, era um problema atribuir um cabeçalho em config.headers com um valor nulo no início do aplicativo (ele puxa um valor do armazenamento local e, inicialmente, não há nada lá). Atribuir o valor a uma string vazia quando o valor é nulo resolve o problema. Eu me pergunto se isso é algo que pode ou deve ser tratado dentro de axios (não tenho certeza se há valor em passar cabeçalhos nulos para xhr se ele quebrar _ às vezes_).

Para outros com um problema semelhante, descobri que alguns clientes VPN também podem bloquear solicitações OPTIONS (veja aqui )

O erro CORS enganoso ainda está em axios. O polyfill fetch suporta mode: 'no-cors' para corrigir este problema.

Precisamos fazer esses tipos de solicitações para fazer solicitações em máquinas em outros ambientes que operamos, bem como na mesma máquina em portas diferentes!

@dreki Forneça a descrição do problema que você mencionou.

Você não pode fazer nada no lado do cliente, quando o servidor simplesmente não aceita solicitações de sua origem. Se você pudesse, teríamos um enorme vazamento de segurança aqui (e com "nós", quero dizer toda a Internet) ...

Acho que axios age e reage de forma totalmente conforme aqui.

O cabeçalho de resposta importante é Access-Control-Allow-Origin que basicamente define as origens válidas, que têm permissão para chamar este serviço do lado do servidor. Se o seu cliente não estiver ligando de nenhuma dessas origens configuradas, a solicitação será recusada com um erro de console como este:

XMLHttpRequest não pode carregar http: // localhost : 8080 / v1 / api / search? Q = candles. Nenhum cabeçalho 'Access-Control-Allow-Origin' está presente no recurso solicitado. Portanto, o acesso de origem ' http: // localhost : 9999' não é permitido.

Você não está na lista de convidados.

Resolvido meu problema.
Estava tentando acessar minha api expressa em localhost:3000 do meu aplicativo vue em localhost:8080 , mas estava obtendo um erro de volta.
Acontece que você precisa adicionar http:// para que funcione.
Portanto, use http://localhost:3000 vez de localhost:3000 ao fazer o teste de desenvolvimento.

Eu tive o mesmo problema com a API wikmedia. olhando em sua página CORS (https://www.mediawiki.org/wiki/Manual:$wgCrossSiteAJAXdomains), adicionei origin = * à solicitação e corrigiu o problema.

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

Mesmo tendo recebido a mensagem de erro assustadora de cors, meu pedido estava chegando ao servidor.

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, por favor, consertem ???

@mellogarrett Este não é um problema relacionado aos axios. Leia isto: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Citação importante:

"Por motivos de segurança, os navegadores restringem as solicitações HTTP de origem cruzada iniciadas nos scripts. Por exemplo, XMLHttpRequest e Fetch seguem a política de mesma origem. Portanto, um aplicativo da web que usa XMLHttpRequest ou Fetch só pode fazer solicitações HTTP para seu próprio domínio. Para para melhorar os aplicativos da web, os desenvolvedores pediram aos fornecedores de navegadores que permitissem solicitações de domínio cruzado. "

Muitos dos que estão tendo esse problema provavelmente não têm o servidor respondendo à solicitação OPTIONS. Certifique-se de ter manipuladores (com cabeçalhos CORS) para solicitações OPTIONS e POST. O cliente (axios) irá primeiro fazer ping em OPTIONS e, em seguida, fazer o POST.

Eu tenho o mesmo erro no Firefox, mas não no Chromium. Então lembrei que o NoScript estava lá (no Firefox) impedindo a solicitação para o servidor remoto. Caso você tenha NoScript (ou um plugin semelhante) instalado, verifique primeiro.
No meu caso, o problema não era relacionado ao Axios. Obrigado pelo ótimo trabalho.

Para qualquer outra pessoa que buscasse uma solução para esse problema, eu tinha os mesmos sintomas, mas rastreiei o problema até uma configuração do php.ini no servidor.

Minha solicitação OPTIONS de comprovação foi bem-sucedida e seguida por uma solicitação POST adequada, mas eu ainda estava recebendo No 'Access-Control-Allow-Origin' header is present on the requested resource... semelhante a @mellogarrett . Isso parecia totalmente estranho, então usei um plugin do Chrome para desabilitar temporariamente a proteção CORS. Depois disso, pude ver que o problema era na verdade um erro de 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

Este post tem mais informações sobre o problema, mas em resumo, se você estiver usando o PHP 5.6, você deve descomentar always_populate_raw_post_data em seu php.ini e definir como -1 . Espero que isso poupe algumas horas de solução de problemas para outra pessoa 🤓

Olá @daltonamitchell, parece que estou tendo o mesmo problema (as condições sugerem que é o mesmo problema). Mas estou me perguntando: como você descobriu que o erro de dados de postagem brutos era o problema? Ao usar o plug-in do Chrome, você mencionou, a solicitação CORS é processada e tudo funciona bem. Mas, embora os cabeçalhos estejam configurados corretamente, não consigo fazê-lo funcionar sem o plug-in. Portanto, talvez a mensagem de descontinuação não seja exibida, mas o problema ainda pode estar lá ...? Você pode dar alguns conselhos sobre como verificar isso?

@ RT-TL o plugin é usado apenas para ver o conteúdo da resposta sem o bloqueio do CORS. No meu caso, para fins de teste, estava apenas retornando uma string como Hello World então, quando desativei o CORS, vi algo como

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

Certifique-se de ter os avisos do PHP habilitados adicionando error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE) ou error_reporting(E_ALL) ao topo do seu método de controlador. Se você ainda não vir nada, eu tentaria retornar alguma resposta JSON simples para verificar se eles têm a aparência esperada.

Alguém ainda está tendo esse problema? Estou correndo para o mesmo:

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

Cabeçalhos de resposta

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

Solicitar cabeçalhos

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

Não consigo descobrir por que nenhum dos meus cabeçalhos está sendo enviado corretamente.

Mesmo problema aqui, a solicitação OPTIONS é feita, mas a solicitação POST não.

TLDR: fetch funciona, axios não, a menos que eu use JSON.stingify

Portanto, também vi a variante desse erro em que OPTIONS retorna 200 com os cabeçalhos definidos para solicitações de origem cruzada, mas nenhum POST é feito. Eu uso essa extensão e ela começa a funcionar conforme o esperado. Mas tenho certeza de que há algum tipo de problema aqui. Dê uma olhada em minha solicitação:

Meu servidor está respondendo com Access-Control-Allow-Origin: *
Aqui estão todos os exemplos com código e capturas de tela:

Axios:

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

buscar:

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

com JSON.stringify

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

Consegui fazer os axios funcionarem JSON.stringify -ing meus dados assim:

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

Eu estava enfrentando o mesmo problema que @kwhitaker explicou, a axios não estava enviando meu cookie corretamente, resultando em respostas com menos informações (suponho que devido a questões de segurança). Por outro lado, a solicitação XHR regular funcionou bem. Então, como @zlyi sugeriu, eu apenas adicionei a linha axios.defaults.withCredentials = true; e tudo começou a funcionar conforme o esperado.

Tentei de tudo e continuo tendo o problema. :(

Tentei de tudo e continuo tendo o problema. :(

conseguiram resolver o problema adicionando o seguinte a .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>

Consegui resolver isso usando um proxy. Adicione o proxy ao package.json

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

Então solicite:

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

Este é um problema do lado do servidor, precisa ter 'Acces-Control-Allow-Origin': '*' em seu cabeçalho de resposta. Se você estiver usando Express, pode usar npm-cors para uma implementação mais robusta / elegante.

+1 @ProfNandaa
Eu criei uma exportação no meu servidor 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();
}

então eu atribuo:
`` `
const cors = require ('cors');
router.use (cors);
`` ``
agora siga em frente ... obrigado

O erro acontecerá quando o servidor não aceitar a solicitação de OPÇÃO.

Para aqueles que comentam dizendo "Adicionar tratamento de solicitação de OPÇÃO ao seu servidor", isso não funciona. Estou executando um ambiente local que tem o tratamento de solicitação OPTION habilitado.

Eu experimentei esse problema de forma idêntica ao do usuário acima, onde Axios.post(url, obj) retornou o erro proibido CORS 403, mas atualizar para Axios.post(url, JSON.stringify(obj)) funcionou corretamente.

Estou trabalhando em apenas um projeto de tutorial simples e tive problemas para acessar vários apis. A única solução que encontrei para funcionar é a mencionada por thiagodebastos acima.

Simplesmente substituí get jsonp por get e consegui acessar os dados.

Eu tive esse problema e o koa-cors foi uma solução simples! (npm-cors para usuários Express de acordo com ProfNandaa)

Para aqueles que ainda estão tendo problemas com isso: Axios funcionará bem com CORs , com solicitações OPTIONS, com JSON enviado como o corpo da solicitação sem ser JSON.encoded , e com cookies enviados e persistidos corretamente, desde que Axios e o servidor que responde às solicitações está configurado corretamente.

Demorou algumas tentativas e erros frustrantes, mas temos solicitações de vários domínios funcionando bem com o Axios.

Alguns pontos:

Para que a solicitação funcione, certifique-se de

• O servidor responde às solicitações OPTIONS, como se a resposta fosse qualquer outra diferente de 200 com todos os cabeçalhos corretos definidos, as solicitações "pré-iluminadas" falharão.

• A solicitação é feita com os cabeçalhos corretos e o servidor responde com todos os cabeçalhos necessários.

• Se cookies / cabeçalhos de autorização ou certificados de cliente TLS forem necessários, envie allowCredentials para true para a solicitação do Axios. Isso pode ser feito por padrão ( axios.defaults.withCredentials = true ) ou por solicitação.

Exemplo de cabeçalhos de solicitação bem-sucedidos

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

Exemplos de cabeçalhos de resposta bem-sucedidos

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

Gradualmente adicionamos cabeçalhos de resposta e descobrimos que tínhamos vários erros difíceis de diagnosticar e comportamento inesperado com diferentes combinações

Sem Access-Control-Allow-Credentials: true cookies não eram enviados ou persistidos, o que faz sentido depois de ler a página MDN desse cabeçalho

Ler esta documentação ajuda.

Qualquer pessoa com o problema, ...Allow-Headers: Content-Type é importante.

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

Estou usando esta extensão do Chrome chamada 'Allow-Control-Allow-Origin: *'
espero que possa ajudar seu problema.

Para quem não entende porque o Axios NÃO PODE corrigir este erro:

Este não é um problema do Axios. É um problema com o navegador. JS no navegador rejeitará solicitações para servidores que não possuem os cabeçalhos adequados definidos. Se você estiver usando isso com algo como React no cliente, não se confunda, este não é um problema de React ou Axios, é simplesmente o navegador respeitando o padrão CORS.

JakeElder fornece uma boa descrição do que você precisa fazer no lado do servidor de sua API aqui: https://github.com/mzabriskie/axios/issues/191#issuecomment -311069164

Se você não tem controle sobre o servidor que está tentando acessar, deve criar um servidor proxy para buscar o conteúdo para você e devolvê-lo com os cabeçalhos corretos.

Não sei por que isso foi implementado. Com certeza é irritante quando você quer apenas fazer uma solicitação a um servidor para obter algumas informações, mas não pode porque o servidor não tem um cabeçalho específico definido. Parece extremamente restritivo. Ah bem ...

@ robins-eldo Mais uma vez, não acredito que você esteja certo.

Meu comentário original:

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.

Se fosse de fato um problema do servidor, e não um problema do Axios, a string de um objeto não teria efeito, pois a solicitação OPTIONS teria falhado de qualquer maneira.

@alexanderbanks

Não tenho certeza sobre o método OPTION HTTP, mas meu problema específico é que tenho um cliente React tentando fazer um POST para uma API interna que escrevi (a API interna é o servidor aqui). Continuei recebendo este erro: 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.

Achei que fosse um problema do Axios, então tentei o Unirest e continuei recebendo o mesmo erro. Então eu percebi que deveria ser outra coisa. Não tenho certeza se isso é um problema de navegador ou React, mas assim que adicionei o seguinte ao meu servidor de API (que é uma API Nodejs + Express), tudo começou a funcionar com Axios e Unirest no lado do cliente:

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

Talvez minha compreensão do que realmente está acontecendo nos bastidores aqui seja um pouco limitada, no entanto, esse pedaço de código no servidor resolveu o problema para mim.

Certifique-se de que o seu servidor não esteja restringindo muito o acesso à origem e se você quiser evitar problemas, tente o seguinte:

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

Acho que há algumas pessoas aqui confusas sobre como o CORS funciona. No entanto, o problema original não era sobre CORS, ou pelo menos esse deveria ser o problema importante. Quer dizer, quando você tem o CORS configurado corretamente, mas mesmo que o Post não funcione, então isso é um problema para relatar, não como configurar um servidor corretamente

API agindo de forma estranha. Todas as solicitações GET do cors estavam funcionando com "credentials: true".
Para solicitações POST, a mesma solicitação de origem está funcionando sem stringify objeto de dados, enquanto para solicitação CORS POST também começa a funcionar quando i stringify objeto de dados.

Não entendi exatamente o motivo, mas o problema foi resolvido para mim.

Sinto muito, mas estou bloqueando este tópico, pois parece que estamos fazendo círculos em torno do mesmo tópico. Se você tiver um problema específico que não foi abordado em outro problema (problemas gerais de CORS devido a configuração incorreta, solicitações POST enviadas como JSON em vez de form-urlencoded, etc.), abra um novo com detalhes específicos.