express - nodejs - El campo de encabezado de solicitud Access-Control-Allow-Headers no está permitido por sí mismo en la respuesta previa al vuelo

nodejs npm install cors

Question

Me he encontrado con problemas de CORS varias veces y generalmente puedo solucionarlo, pero realmente quiero entender al ver esto desde un paradigma de pila MEAN.

Antes simplemente agregué middleware en mi servidor express para detectar estas cosas, pero parece que hay algún tipo de preenganche que está errando mis solicitudes.

El campo de encabezado de solicitud Access-Control-Allow-Headers no está permitido por Access-Control-Allow-Headers en la respuesta previa al vuelo

Supuse que podía hacer esto:

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

o el equivalente, pero esto no parece solucionarlo. También, por supuesto, intenté

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

Aún sin suerte.

Answer 1

Acabo de encontrarme con este problema, en el contexto de ASP.NET, asegúrese de que su Web.config se vea así:

 <system.webServer>
<modules>
<remove name="FormsAuthentication" />
</modules>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<!--<remove name="OPTIONSVerbHandler"/>-->
<remove name="TRACEVerbHandler" />
<!--
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
-->
</handlers>
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type, Authorization" />
<add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
</customHeaders>
</httpProtocol>

Observe el valor de Autorización para la clave Access-Control-Allow-Headers . Me faltaba el valor de Autorización, esta configuración resuelve mi problema.

Answer 2

Cuando comience a jugar con encabezados de solicitud personalizados, obtendrá una verificación previa de CORS. Esta es una solicitud que utiliza el verbo OPTIONS HTTP e incluye varios encabezados, uno de los cuales es Access-Control-Request-Headers enumera los encabezados que el cliente desea incluir en la solicitud.

Debe responder a esa verificación previa CORS con los encabezados CORS apropiados para que esto funcione. Uno de los cuales es, de hecho, Access-Control-Allow-Headers . Ese encabezado debe contener los mismos valores que el Access-Control-Request-Headers (o más).

https://fetch.spec.whatwg.org/#http-cors-protocol explica esta configuración con más detalle.

Answer 3

Después de pasar casi un día, descubrí que agregar los dos códigos a continuación resolvió mi problema.

Agregue esto en Global.asax

 protected void Application_BeginRequest()
{
if (Request.HttpMethod == "OPTIONS")
{
Response.StatusCode = (int)System.Net.HttpStatusCode.OK;
Response.End();
}
}

y en la configuración web agregue el siguiente

 <httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
<add name="Access-Control-Allow-Methods" value="*" />
<add name="Access-Control-Allow-Headers" value="Content-Type, Authorization" />
</customHeaders>
</httpProtocol>

Answer 4

El mensaje es claro que "Autorización" no está permitido en la API. Conjunto
Access-Control-Allow-Headers: "Tipo de contenido, Autorización"

Answer 5

En cromo:

El campo de encabezado de solicitud X-Solicitado-con no está permitido por Access-Control-Allow-Headers en la respuesta previa al vuelo.

Para mí, este error fue provocado por un espacio final en la URL de esta llamada.

jQuery.getJSON( url, function( response, status, xhr ) {
...
}

Answer 6

En la llamada Post API estamos enviando datos en el cuerpo de la solicitud. Entonces, si enviaremos datos agregando cualquier encabezado adicional a una llamada API. Luego, se realizará la primera llamada de OPTIONS API y luego se realizará la llamada posterior. Por lo tanto, primero debe manejar la llamada OPTION API.

Puede manejar el problema escribiendo un filtro y dentro de eso debe verificar la opción de llamada a la llamada API y devolver un estado de 200 OK. A continuación se muestra el código de muestra:

package com.web.filter;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.connector.Response;
public class CustomFilter implements Filter {
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
throws IOException, ServletException {
HttpServletResponse response = (HttpServletResponse) res;
HttpServletRequest httpRequest = (HttpServletRequest) req;
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, GET, PUT, OPTIONS, DELETE");
response.setHeader("Access-Control-Max-Age", "3600");
response.setHeader("Access-Control-Allow-Headers", "x-requested-with, Content-Type");
if (httpRequest.getMethod().equalsIgnoreCase("OPTIONS")) {
response.setStatus(Response.SC_OK);
}
chain.doFilter(req, res);
}
public void init(FilterConfig filterConfig) {
// TODO
}
public void destroy() {
// Todo
}
}

Answer 7

Ese mismo problema que estaba enfrentando.

Hice un cambio simple.

 <modulename>.config(function($httpProvider){
delete $httpProvider.defaults.headers.common[''X-Requested-With''];
});

Answer 8

Este problema ocurre cuando hacemos un encabezado personalizado para la solicitud. Esta solicitud utiliza las HTTP OPTIONS e incluye varios encabezados.

El encabezado requerido para esta solicitud es Access-Control-Request-Headers , que debe ser parte del encabezado de respuesta y debe permitir la solicitud desde todo el origen. A veces también necesita Content-Type en el encabezado de respuesta. Entonces su encabezado de respuesta debería ser así:

 response.header("Access-Control-Allow-Origin", "*"); // allow request from all origin
response.header("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
response.header("Access-Control-Allow-Headers", "Access-Control-Allow-Headers, Origin, X-Requested-With, Content-Type, Accept, Authorization");

Answer 9

Este problema resuelto con

 "Origin, X-Requested-With, Content-Type, Accept, Authorization"

Particular en mi proyecto (express.js / nodejs)

app.use(function(req, res, next) {
res.header("Access-Control-Allow-Origin", "*");
res.header("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization");
next();
});

Actualizar:

Error cada vez: Access-Control-Allow-Headers is not allowed by itself in preflight response error de Access-Control-Allow-Headers is not allowed by itself in preflight response verificación Access-Control-Allow-Headers is not allowed by itself in preflight response , puede ver qué sucede con la herramienta de desarrollador de Chrome :

Falta el tipo de Content-Type así que agregue la cadena Content-Type a Access-Control-Allow-Headers

Answer 10

Esto es lo que necesita agregar para que funcione.

 response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Credentials", "true");
response.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
response.setHeader("Access-Control-Allow-Headers", "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers");

El navegador envía una solicitud de verificación previa (con el tipo de método OPTIONS) para verificar si se puede acceder al servicio alojado en el servidor desde el navegador en un dominio diferente. En respuesta a la solicitud de verificación previa si inyecta encabezados anteriores, el navegador comprende que está bien hacer más llamadas y obtendré una respuesta válida a mi llamada GET / POST real. puede restringir el dominio al que se otorga el acceso utilizando Access-Control-Allow-Origin "," localhost, xvz.com "en lugar de *. (* otorgará acceso a todos los dominios)

Answer 11

La respuesta aceptada está bien, pero tuve dificultades para entenderla. Así que aquí hay un ejemplo simple para aclararlo.

En mi solicitud ajax, tenía un encabezado de autorización estándar.

 $$(document).on(''ajaxStart'', function(e){
var auth_token = localStorage.getItem(SB_TOKEN_MOBILE);
if( auth_token ) {
var xhr = e.detail.xhr;
xhr.setRequestHeader(''**Authorization**'', ''Bearer '' + auth_token);
}

Este código produce el error en la pregunta. Lo que tenía que hacer en mi servidor nodejs era agregar Autorización en los encabezados permitidos:

res.setHeader(''Access-Control-Allow-Headers'', ''X-Requested-With,content-type,**Authorization**'');

Answer 12

Muy bien, usé esto en un proyecto de silex

$app->after(function (Request $request, Response $response) {
$response->headers->set(''Access-Control-Allow-Origin'', ''*'');
$response->headers->set("Access-Control-Allow-Credentials", "true");
$response->headers->set("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
$response->headers->set("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept, Authorization");
});

Answer 13

Para agregar a las otras respuestas. Tuve el mismo problema y este es el código que utilicé en mi servidor express para permitir llamadas REST:

 app.all(''*'', function(req, res, next) {
res.header(''Access-Control-Allow-Origin'', ''URLs to trust of allow'');
res.header(''Access-Control-Allow-Methods'', ''GET, POST, OPTIONS, PUT, PATCH, DELETE'');
res.header(''Access-Control-Allow-Headers'', ''Content-Type'');
if (''OPTIONS'' == req.method) {
res.sendStatus(200);
} else {
next();
}
});

Lo que básicamente hace este código es interceptar todas las solicitudes y agregar los encabezados CORS, luego continuar con mis rutas normales. Cuando hay una solicitud de OPCIONES, solo responde con los encabezados CORS.

EDITAR: Estaba usando esta solución para dos servidores express nodejs separados en la misma máquina. Al final solucioné el problema con un servidor proxy simple.

Answer 14

Recibí el error que el OP declaró usando Django, React y django-cors-headers lib. Para solucionarlo con esta pila, haga lo siguiente:

En settings.py agregue lo siguiente según la documentación oficial .

from corsheaders.defaults import default_headers
CORS_ALLOW_HEADERS = default_headers + (
''YOUR_HEADER_NAME'',
)

Answer 15

Solo para agregar que puede colocar esos encabezados también en el archivo de configuración de Webpack. Los necesitaba como en mi caso, ya que estaba ejecutando el servidor de desarrollo webpack.

devServer: {
headers: {
"Access-Control-Allow-Origin": "*",
"Access-Control-Allow-Credentials": "true",
"Access-Control-Allow-Methods": "GET,HEAD,OPTIONS,POST,PUT",
"Access-Control-Allow-Headers": "Origin, X-Requested-With, Content-Type, Accept, Authorization"
},

Answer 16

Yo también enfrenté el mismo problema en Angular 6. Resolví el problema usando el siguiente código.

Add the code in component.ts file.
import { HttpHeaders } from ''@angular/common/http'';
headers;
constructor() {
this.headers = new HttpHeaders();
this.headers.append(''Access-Control-Allow-Headers'', ''Authorization'');
}
getData() {
this.http.get(url,this.headers). subscribe (res => {
your code here...
})
}

Answer 17

res.setHeader (''Access-Control-Allow-Headers'', ''*'');