Axios: no puede hacer que funcione POST entre sitios

Además, también estoy configurando withCredentials como verdadero en el archivo config.

También me encontré con este problema y parece que solo me ocurre en Mac. Pasé unos buenos 3 días y noches tratando de depurar mi red y decidí por capricho probar esto usando una solicitud XHR de vainilla y me di cuenta de que el problema no era mi red, sino axios.

Yo también estoy haciendo solicitudes entre sitios con credenciales configuradas como verdaderas. Al mirar la solicitud de red, obtiene un ERR_EMPTY_RESPONSE y es como si la solicitud fallara incluso antes de salir del navegador.

Esta es mi configuración:

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 tengo la oportunidad, intentaré investigar esto más a fondo.

Oh bien, no estoy loco. :) Por favor, mire esto si es posible.

Resulta que mi problema no estaba relacionado con Axios. Cisco Anyconnect estaba bloqueando las solicitudes de opciones de mi máquina ... ¿por qué?

Las solicitudes entre dominios no requieren ninguna configuración adicional. Volverá a usar XDomainRequest para IE más antiguos. https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js#L22

puedes darme mas detalles? Qué navegador, sistema operativo, versión de axios, cualquier mensaje de error.

No puedo hablar por Jenny, pero algo en particular esta biblioteca hace que las solicitudes sean bloqueadas por la seguridad predeterminada de Cisco Anyconnect, lo que significa que es posible que otras configuraciones de seguridad también lo hagan. Estoy tratando de rastrear esto, pero no he tenido suerte hasta ahora.

Esto se puede reproducir haciendo una solicitud entre sitios en una Mac instalada con Cisco Anyconnect y posiblemente con otros clientes VPN.

Mi entorno es:

• Axios 0.8.1
• El Capitán
• Cromo
• Mensaje de error: "No hay un encabezado 'Access-Control-Allow-Origin' presente en el recurso solicitado. Por lo tanto, no se permite el acceso al origen ' http: // localhost : 3000'".

Tenga en cuenta que la misma solicitud funciona con curl.

¡Gracias por mirar en esto!

Con CORS, se realiza una solicitud de verificación previa al servidor para ver si la solicitud está permitida. Necesitará que su servidor responda a las solicitudes que tienen OPTIONS como método de solicitud configurando el encabezado Acces-Control-Allow-Origin: * que permitirá solicitudes de cualquier origen. Alternativamente, puede permitir solo ciertos orígenes Acces-Control-Allow-Origin: http://example.com .

Sí, lo entiendo. Pero el servidor no es mío. Estoy usando un Baas (backend-as-a-service). Y ya agregaron mi dominio a la lista de permitidos. He comprobado que otras personas que utilizan dicho Baas no han tenido este tipo de problemas.

Solo estoy apagando el mensaje de error que proporcionaste, pero en base a eso no parece que tu baas tenga cosas que funcionen para ti. No fallaría al usar curl porque la seguridad de origen cruzado es solo una limitación dentro del navegador.

¿Puede abrir la pestaña de red en su navegador y compartir lo que obtiene como respuesta a la solicitud de OPCIONES? Con suerte, ver los datos de respuesta y los encabezados ayudará a depurar este problema.

Gracias

Aquí están los encabezados:

Aquí están los encabezados de respuesta de GitHub cuando uso axios para obtener mi perfil de usuario de su API:

Puede ver que GitHub agrega Access-Control-Allow-Origin: * . La respuesta de su Baas no tiene encabezados de tipo Access-Control .

Veo veo hmm. Perdón por la respuesta súper tardía. Déjame ver esto un poco más. Muchísimas gracias.

No estoy seguro de si lo que veo está relacionado o no. Básicamente, puedo enviar una solicitud de autenticación a nuestro servidor remoto y recuperar una cookie, pero luego las llamadas posteriores al servidor _no_ envían las cookies junto con ellas, lo que genera un error.

Aquí están los encabezados de la llamada POST para iniciar sesión:

Y ahora una llamada de seguimiento GET :

La dirección IP que figura en origin es la mía, por lo que no debería ser un problema. Si este no es el lugar adecuado para esto, me complace crear un nuevo número o adjuntarlo al que ya exista.

Como una nueva arruga; Probé una llamada de seguimiento GET usando solo XHR directo, y la cookie se envía sin problemas. Sin embargo, hacer la misma llamada a través de Axios da como resultado el mismo problema que mencioné anteriormente.

Puaj. Por favor ignore - No estaba enviando cosas como esperaba a través de Axios :)

También estoy enfrentando el mismo problema.
OPCIONES La llamada pasa, pero las llamadas POST se atascan en cors.
http://stackoverflow.com/questions/36907693/axios-cors-issue-with-github-oauth-not-getting-access-token

¿Cómo no se aborda un problema tan ENORME?

+1

+1

+1

+1

+1

+1

+1

@dsacramone ¿cuál es el problema que está viendo? Parece que la mayoría de los problemas que se informan son problemas con el servidor o falsas alarmas. Si hay un error reproducible que pueda ver, me complace trabajar en una solución.

obteniendo esto también

XMLHttpRequest no puede cargar https://en.wikipedia.org/w/api.php?action=opensearch&format=json&search=fish. No hay un encabezado 'Access-Control-Allow-Origin' presente en el recurso solicitado. Por lo tanto, no se permite el acceso al origen ' http: // localhost : 3000'.

también conseguirlo usando fetch to note. Creo que su Chrome recientemente ha hecho que su política de configuración de solicitudes sea más estricta, creo que necesitará algún tipo de encabezado (aunque no estoy seguro de qué).

aquí hay un ejemplo (ambos servidos a través de https)

Ejemplo 1: funciona bien

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

Exampel 2 - No funciona - ¿Muestra un error?

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

aquí está la respuesta de error

[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 podría ser relevante está en transformResponse? Me pregunto qué significa PROTECTION_PREFIX bit.

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

incluso intentando

modo: 'no-cors'
in fetch todavía da este error

Estoy seguro de que las respuestas son bastante simples y solo necesita algún tipo de encabezado, pero no estoy seguro de qué, seguirá jugando.

la API de wikipedia podría ser un ejemplo inestable, ¿el mismo error en otros?

Elimino este código, puedo funcionar: axios.defaults.withCredentials = true

Conseguí que la API de wikipedia funcionara bien con 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);
  }
});

No se requieren configuraciones adicionales.

Obteniendo el mismo error con axios. Aquí está mi 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>
    )
  }
}

_Nota: puedo acceder a la API perfectamente bien con la solicitud de nodo.

Me encuentro con el mismo error que @Sinistralis . En la última versión de Chrome en Mac OSX, obtengo net::ERR_EMPTY_RESPONSE en las solicitudes CORS que se realizan correctamente (mi servidor maneja bien todos los encabezados CORS, incluidas las OPCIONES). Es extraño porque en iOS10 safari, exactamente el mismo código funciona sin problemas. Intentaré investigar un poco más por mi cuenta para ver cómo se puede resolver esto.

En una Mac anterior (10.11) con la última versión de Chrome, no puedo reproducir este error con exactamente el mismo código. Esto es realmente muy extraño. Es posible que pueda reproducirlo visitando esta aplicación muy simple: http://lights.suyashkumar.com e inspeccionando la consola (el código está aquí . En algunas máquinas no habrá ningún error y lo redireccionará para iniciar sesión. En otras no lo redireccionará y lo dejará en la página principal.

Resuelto mi error. Para mí, fue un problema asignar un encabezado en config.headers con un valor nulo al iniciar la aplicación (extrae un valor del almacenamiento local e inicialmente, no hay nada). Asignar el valor a una cadena vacía cuando el valor es nulo resuelve el problema. Me pregunto si esto es algo que puede o debe manejarse dentro de axios (no estoy seguro de si hay valor en pasar encabezados nulos a xhr si se rompe _sometimes_).

Para otros con un problema similar, descubrí que algunos clientes de VPN también pueden bloquear las solicitudes de OPCIONES (ver aquí )

El error CORS engañoso todavía está en axios. El polyfill fetch admite mode: 'no-cors' para solucionar este problema.

Necesitamos hacer este tipo de solicitudes para realizar solicitudes contra máquinas en otros entornos en los que operamos, ¡así como en la misma máquina en diferentes puertos!

@dreki Proporcione la descripción del problema que mencionó.

No puede hacer nada en el lado del cliente, cuando el servidor simplemente no acepta solicitudes de su origen. Si pudiera, tendríamos una gran filtración de seguridad aquí (y con "nosotros" me refiero a todo Internet) ...

Creo que axios actúa y reacciona totalmente de acuerdo aquí.

El encabezado de respuesta importante es Access-Control-Allow-Origin que básicamente establece los orígenes válidos que pueden llamar a este servicio del lado del servidor. Si su cliente no llama desde ninguno de estos orígenes configurados, la solicitud se rechazará con un error de consola como este:

XMLHttpRequest no puede cargar http: // localhost : 8080 / v1 / api / search? Q = candles. No hay un encabezado 'Access-Control-Allow-Origin' presente en el recurso solicitado. Por lo tanto, no se permite el acceso al origen ' http: // localhost : 9999'.

No estás en la lista de invitados.

Arreglado mi problema.
Intentaba acceder a mi api exprés en localhost:3000 desde mi aplicación vue en localhost:8080 , pero recibía un error.
Resulta que necesitas agregar http:// para que funcione.
Por lo tanto, use http://localhost:3000 lugar de localhost:3000 cuando realice pruebas de desarrollo.

Tuve el mismo problema con la API de wikmedia. mirando en su página CORS (https://www.mediawiki.org/wiki/Manual:$wgCrossSiteAJAXdomains) agregué origin = * a la solicitud y solucionó el 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); })

Aunque recibí el mensaje de error scary cors, mi solicitud estaba llegando al 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.

Equipo de Axios, ¿puede arreglarlo?

@mellogarrett Este no es un problema relacionado con axios. Lea esto: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Cita importante:

"Por razones de seguridad, los navegadores restringen las solicitudes HTTP de origen cruzado iniciadas desde dentro de scripts. Por ejemplo, XMLHttpRequest y Fetch siguen la política del mismo origen. Por lo tanto, una aplicación web que utilice XMLHttpRequest o Fetch solo podría realizar solicitudes HTTP a su propio dominio. Para mejorar las aplicaciones web, los desarrolladores pidieron a los proveedores de navegadores que permitieran solicitudes entre dominios ".

Muchos de los que tienen este problema probablemente no tienen el servidor respondiendo a la solicitud de OPCIONES. Asegúrese de tener controladores (con encabezados CORS) para las solicitudes OPTIONS y POST. El cliente (axios) primero hará ping a OPTIONS y luego hará la POST.

Tengo el mismo error en Firefox, pero no en Chromium. Entonces recordé que NoScript estaba allí (en Firefox) impidiendo la solicitud al servidor remoto. En caso de que tenga NoScript (o un complemento similar) instalado, verifique eso primero.
En mi caso, el problema no estaba relacionado con Axios. Gracias por el gran trabajo.

Para cualquier otra persona que busque en Google una solución a este problema, tuve los mismos síntomas, pero rastreé el problema hasta una configuración de php.ini en el servidor.

Mi solicitud de OPCIONES de verificación previa fue exitosa y seguida de una solicitud POST adecuada, pero todavía recibía No 'Access-Control-Allow-Origin' header is present on the requested resource... similar a @mellogarrett . Esto parecía totalmente extraño, así que usé un complemento de Chrome para deshabilitar temporalmente la protección CORS. Después de eso, pude ver que el problema era en realidad un error 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

Esta publicación tiene más información sobre el problema, pero en resumen, si está usando PHP 5.6, debe descomentar always_populate_raw_post_data en su php.ini y configurarlo en -1 . Espero que esto le ahorre a alguien más algunas horas de resolución de problemas 🤓

Hola @daltonamitchell Parece que estoy teniendo el mismo problema (las condiciones sugieren que es el mismo problema). Pero me pregunto: ¿Cómo se dio cuenta de que el error en los datos de la publicación sin procesar era el problema? Al usar el complemento de Chrome, mencionaste que la solicitud CORS se procesa y todo funciona bien. Pero a pesar de que los encabezados están configurados correctamente, no puedo hacer que funcione sin el complemento. Entonces, ¿tal vez el mensaje de desaprobación simplemente no se muestra, pero el problema podría seguir ahí ...? ¿Puede darnos algún consejo sobre cómo comprobarlo?

@ RT-TL, el complemento solo se usa para ver el contenido de la respuesta sin que CORS lo bloquee. En mi caso, para propósitos de prueba, solo estaba devolviendo una cadena como Hello World así que una vez que desactivé 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

Asegúrese de tener habilitadas las advertencias de PHP agregando error_reporting(E_ERROR | E_WARNING | E_PARSE | E_NOTICE) o error_reporting(E_ALL) en la parte superior de su método de controlador. Si aún no ve nada, solo intentaré devolver una respuesta JSON simple para verificar que se vean como se esperaba.

¿Alguien sigue experimentando este problema? Me estoy encontrando con lo mismo:

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

Encabezados de respuesta

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 encabezados

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

No puedo entender por qué ninguno de mis encabezados se envía correctamente.

El mismo problema aquí, se realiza la solicitud de OPCIONES, pero no la solicitud POST.

TLDR: fetch funciona, axios no a menos que use JSON.stingify

Entonces, también he visto la variante de este error donde OPTIONS devuelve 200 con los encabezados configurados para solicitudes de origen cruzado, pero no se realiza POST. Utilizo esta extensión y comienza a funcionar como se esperaba. Pero estoy bastante seguro de que hay algún tipo de problema aquí. Eche un vistazo a mi solicitud:

Mi servidor responde con Access-Control-Allow-Origin: *
Aquí están todos los ejemplos con código y capturas de pantalla:

Axios:

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

ha podido recuperar:

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

con JSON.stringify

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

Pude hacer que axios funcionara JSON.stringify -ing mis datos así:

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

Estaba enfrentando el mismo problema que @kwhitaker explicó, axios no estaba enviando mi cookie correctamente, lo que resultó en respuestas con menos información (supongo que debido a problemas de seguridad). Por otro lado, la solicitud XHR regular funcionó bien. Luego, como sugirió @zlyi , simplemente agregué la línea axios.defaults.withCredentials = true; y todo comenzó a funcionar como se esperaba.

Intenté todo y sigo teniendo el problema. :(

Intenté todo y sigo teniendo el problema. :(

han manejado el problema agregando lo siguiente 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>

Pude abordar esto usando un proxy. Agregue el proxy al package.json

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

Entonces solicite:

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

Este es un problema del lado del servidor, debe tener 'Acces-Control-Allow-Origin': '*' en el encabezado de su respuesta. Si está usando Express, puede usar npm-cors para una implementación más robusta / elegante.

+1 @ProfNandaa
he creado una exportación en mi 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();
}

entonces asigno:
''
const cors = require ('cors');
router.use (cors);
`` ``
ahora sigue adelante ... gracias

El error ocurrirá cuando el servidor no acepte la solicitud de OPCIÓN.

Para aquellos que comentan diciendo "Agregar manejo de solicitudes de OPCIÓN a su servidor", eso no funciona. Estoy ejecutando un entorno local que tiene habilitado el manejo de solicitudes OPTION.

Experimenté este problema de manera idéntica a un usuario anterior, donde Axios.post(url, obj) devolvió el error prohibido CORS 403, pero actualizarlo a Axios.post(url, JSON.stringify(obj)) funcionó correctamente.

Estoy trabajando en un simple proyecto tutorial y he tenido problemas para acceder a varias apis. La única solución que he encontrado que funciona es la mencionada anteriormente por thiagodebastos.

Simplemente sustituí jsonp por get y pude acceder a los datos.

¡Tuve este problema y koa-cors fue una solución simple! (npm-cors para usuarios Express según ProfNandaa)

Para aquellos que aún tienen problemas con esto: Axios funcionará bien con COR , con solicitudes OPTIONS, con JSON enviado como el cuerpo de la solicitud sin ser JSON.encoded , y con cookies enviadas y persistentes correctamente, siempre que Axios y el servidor que responde a las solicitudes está configurado correctamente.

Tomó un frustrante ensayo y error, pero tenemos solicitudes entre dominios que funcionan bien con Axios.

Algunos puntos:

Para que la solicitud funcione, asegúrese

• El servidor responde a las solicitudes OPTIONS, como si la respuesta fuera diferente a 200 con todos los encabezados correctos configurados, las solicitudes "preflight" fallarán.

• La solicitud se realiza con los encabezados correctos y el servidor responde con todos los encabezados necesarios.

• Si se requieren cookies / encabezados de autorización o certificados de cliente TLS, envíe allowCredentials a verdadero para la solicitud de Axios. Esto se puede hacer por defecto ( axios.defaults.withCredentials = true ) o por solicitud.

Ejemplos de encabezados de solicitud correctos

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

Ejemplos de encabezados de respuesta satisfactorios

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 agregamos encabezados de respuesta y descubrimos que teníamos varios errores difíciles de diagnosticar y comportamientos inesperados con diferentes combinaciones

Sin Access-Control-Allow-Credentials: true cookies no se enviaron o persistieron, lo que tiene sentido después de leer la página MDN para ese encabezado

La lectura de esta documentación ayuda.

Cualquiera que tenga el problema, ...Allow-Headers: Content-Type es importante.

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

Estoy usando esta extensión de Chrome llamada 'Allow-Control-Allow-Origin: *'
Espero que pueda ayudar a tu problema.

Para cualquiera que no entienda por qué Axios NO PUEDE corregir este error:

Este no es un problema de Axios. Es un problema con el navegador. JS en el navegador rechazará las solicitudes a los servidores que no tengan configurados los encabezados adecuados. Si está usando esto con algo como React en el cliente, no se confunda, esto no es un problema de React o Axios, es simplemente el navegador que respeta el estándar CORS.

JakeElder ofrece una buena descripción de lo que debe hacer en el lado del servidor de su API aquí: https://github.com/mzabriskie/axios/issues/191#issuecomment -311069164

Si no tiene control sobre el servidor al que intenta acceder, debe crear un servidor proxy para obtener el contenido y devolverlo con los encabezados correctos.

No estoy seguro de por qué se implementó. Seguro que es molesto cuando solo desea realizar una solicitud a un servidor para obtener información, pero no puede porque el servidor no tiene un conjunto de encabezados específico. Parece extremadamente restrictivo. Oh bien ...

@ robins-eldo Una vez más, no creo que estés en lo cierto.

Mi comentario 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.

Si de hecho fuera un problema del servidor y no un problema de Axios, la cadena de un objeto no habría tenido ningún efecto, ya que la solicitud de OPCIONES habría fallado de cualquier manera.

@alexanderbanks

No estoy seguro sobre el método OPTION HTTP, pero mi problema específico fue que tengo un cliente React que intenta POST en una API interna que escribí (la API interna es el servidor aquí). Seguí recibiendo este error: 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.

Pensé que podría ser un problema de Axios, así que probé Unirest en su lugar y seguí obteniendo el mismo error. Así que pensé que debía ser otra cosa. No estoy seguro si esto es un problema del navegador o React, pero tan pronto como agregué lo siguiente a mi servidor API (que es una API Nodejs + Express), todo comenzó a funcionar tanto con Axios como con Unirest en el lado del cliente:

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

Quizás mi comprensión de lo que realmente está sucediendo detrás de escena aquí es algo limitada, sin embargo, este fragmento de código en el servidor me resolvió el problema.

Asegúrese de que su servidor no restrinja demasiado el acceso al origen y, si tiene ganas de evitar los no-cors, intente esto:

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

Creo que hay algunas personas aquí confundidas acerca de cómo funciona CORS. Sin embargo, el problema original no tenía que ver con CORS, o al menos ese debería ser el problema importante. Quiero decir, cuando tiene CORS configurado correctamente pero aunque la publicación no funciona, entonces ese es un problema para informar, no cómo configurar un servidor correctamente

API actuando de forma extraña. Todas las solicitudes GET de cors estaban funcionando con "credentials: true".
Para las solicitudes POST, la solicitud del mismo origen funciona sin el objeto de datos de cadena, mientras que para la solicitud CORS POST también comienza a funcionar cuando identifico el objeto de datos.

No entendí exactamente la razón, pero el problema me resolvió.

Lo siento, pero estoy bloqueando este hilo porque parece que estamos haciendo círculos sobre el mismo tema. Si tiene un problema específico que no se ha abordado en otro problema (problemas generales de CORS debido a una configuración incorrecta, solicitudes POST enviadas como JSON en lugar de código de URL de formulario, etc.), abra uno nuevo con detalles específicos.