O campo de header de solicitação Access-Control-Allow-Headers não é permitido sozinho na resposta de comprovação

Eu me deparei com os problemas do CORS várias vezes e geralmente posso corrigi-lo, mas eu realmente quero entender vendo isso de um paradigma de pilha MEAN.

Antes eu simplesmente adicionava middleware no meu servidor expresso para pegar essas coisas, mas parece que há algum tipo de pré-gancho que está errando meus pedidos.

Campo de header de solicitação Access-Control-Allow-Headers não é permitido pelo Access-Control-Allow-Headers na resposta de comprovação

Eu assumi que eu poderia fazer isso:

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

ou o equivalente, mas isso não parece resolvê-lo. Eu também, claro, tentei

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

Ainda sem sorte.

Quando você começa a brincar com headers de solicitação personalizados, você obtém uma pré-impressão do CORS. Essa é uma solicitação que usa o verbo OPTIONS HTTP e inclui vários headers, sendo um deles Access-Control-Request-Headers listando os headers que o cliente deseja include na solicitação.

Você precisa responder a essa preflight do CORS com os headers CORS apropriados para fazer isso funcionar. Uma delas é de fato Access-Control-Allow-Headers . Esse header precisa conter os mesmos valores contidos no header Access-Control-Request-Headers (ou mais).

https://fetch.spec.whatwg.org/#http-cors-protocol explica essa configuração em mais detalhes.

Isso é o que você precisa adicionar 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"); 

O navegador envia uma solicitação de comprovação (com o tipo de método OPTIONS) para verificar se o serviço hospedado no servidor pode ser acessado a partir do navegador em um domínio diferente. Em resposta à solicitação de preflight se você injetar acima dos headers, o navegador entende que está tudo bem fazer outras chamadas e eu receberei uma resposta válida para a minha chamada GET / POST. você pode restringir o domínio ao qual o access é concedido usando Access-Control-Allow-Origin “,” localhost, xvz.com “em vez de *. (* concederá access a todos os domínios)

Este problema resolvido com

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

Particular no meu projeto (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(); }); 

Atualizar:

Toda vez que o erro: Access-Control-Allow-Headers is not allowed by itself in preflight response erro de Access-Control-Allow-Headers is not allowed by itself in preflight response você pode ver o que há de errado com a ferramenta de desenvolvedor do Chrome :
insira a descrição da imagem aqui

erro acima está faltando Content-Type para adicionar string Content-Type para Access-Control-Allow-Headers

A resposta aceita é ok, mas eu tive dificuldades em entender. Então, aqui está um exemplo simples para esclarecer isso.

No meu pedido de ajax eu tinha um header de autorização padrão.

  $$(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 produz o erro na questão. O que eu tive que fazer no meu servidor nodejs foi adicionar Autorização nos headers permitidos:

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

Eu acabei de me deparar com essa questão, no contexto do ASP.NET, verifique se o seu Web.config se parece com isso:

                   

Observe o valor de autorização para a chave Access-Control-Allow-Headers . Eu estava faltando o valor de autorização, esta configuração resolve meu problema.

Muito bom eu usei isso em um projeto 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"); }); 

Para adicionar às outras respostas. Eu tive o mesmo problema e este é o código que eu usei no meu servidor expresso para permitir chamadas 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(); } }); 

O que esse código basicamente faz é interceptar todas as solicitações e adicionar os headers CORS, depois continuar com minhas rotas normais. Quando há uma solicitação OPTIONS, ela responde apenas com os headers CORS.

EDIT: eu estava usando essa correção para dois servidores expressos nodejs separados na mesma máquina. No final, consertei o problema com um servidor proxy simples.

No Chrome:

O campo de header de solicitação X-Requested-With não é permitido por Access-Control-Allow-Headers na resposta de comprovação.

Para mim, esse erro foi acionado por um espaço à direita no URL dessa chamada.

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

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

Só para acrescentar que você pode colocar esses headers também no arquivo de configuração do Webpack. Eu precisava deles, como no meu caso, como eu estava executando o servidor webpack dev.

 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" }, 

Esse problema ocorre quando fazemos o header personalizado para request.This solicitação que usa as HTTP OPTIONS e inclui vários headers.

O header necessário para essa solicitação é Access-Control-Request-Headers , que deve fazer parte do header de resposta e deve permitir a solicitação de toda a origem. Às vezes, ele também precisa do Content-Type no header da resposta. Então o seu header de resposta deve ser assim –

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

Esse mesmo problema que eu estava enfrentando.

Eu fiz uma mudança simples.

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