Use este guia para resolver problemas comuns na janela do console do navegador relacionados à Access-Control-Allow-Origin mensagem de erro. Abaixo estão exemplos de mensagens de erro.
- Falha em carregar... Nenhum cabeçalho "Access-Control-Allow-Origin"
- Solicitação de origem cruzada bloqueada: A política da mesma origem não permite a leitura do recurso remoto ... Motivo: Cabeçalho CORS “Access-Control-Allow-Origin” ausente
- Falha em carregar... A resposta à solicitação de comprovação não passa na verificação de controle de acesso: Nenhum cabeçalho "Access-Control-Allow-Origin" presente no recurso solicitado. Origem ... portanto, não tem permissão de acesso
Este artigo contém os tópicos abaixo.
Causas do erro
Um aplicativo da Web com base em navegador (possivelmente um aplicativo de estrutura de aplicativos) está tentando fazer uma chamada de "entre origens" para obter um "recurso compartilhado" de um serviço da Web externo. Isso é conhecido como solicitação "CORS" (compartilhamento de recursos entre origens).
Há um padrão CORS baseado em navegador que gerencia essas chamadas entre origens. Quando determinadas condições não são atendidas, podem ocorrer erros.
Ele pode estar relacionado a um caso de uso que não é intencionalmente permitido pelo aplicativo da Web do usuário e pelo serviço externo remoto.
quando uma origem (www.origin1.com) chama outra origem (www.origin2.com), isso é chamado de solicitação entre origens. Algumas condições devem estar em vigor para que essa solicitação funcione. O serviço externo sendo chamado (www.origin2.com) precisa retornar o cabeçalho HTTP Access-Control-Allow-Origin em sua resposta.
Se o serviço externo não retornar esse cabeçalho, a adesão do navegador à especificação CORS interrompe a solicitação e um dos erros acima (ou similar) é retornado.
Perguntas sobre solução de problemas
- Qual é o URL do ponto de partida da chamada (também conhecido como "origem")?
Isso às vezes está na própria mensagem de erro. - Como é chamada a URL do serviço externo?
Às vezes, isso aparece na mensagem de erro do console. - O que está sendo recuperado e por quê? É um arquivo PNG? Um script, CSS ou arquivo de fonte? O que exatamente está sendo recuperado e para que está sendo usado?
Isso pode fornecer alguns insights sobre o caso de uso e a importância do ativo desse local remoto. - Esse recurso externo requer autenticação para ser obtido?
Se um redirecionamento for necessário, oAccess-Control-Allow-Origino cabeçalho de resposta pode não ser retornado e a chamada falhará. Copie o URL do recurso diretamente em uma nova aba anônima do navegador. Esse pode ser um bom teste para saber se ele pode ser acessado em circunstâncias gerais (mas não é uma garantia de que funcionará no código do aplicativo da Web. - Você consegue ver a chamada do método OPTIONS HTTP na aba Rede do navegador?
Quando existem cabeçalhos de solicitação personalizados, autenticação ou outras condições na solicitação entre origens, o navegador faz uma chamada HTTP adicional. Isso também é conhecido como chamada "preflight". O código do aplicativo da Web não faz isso explicitamente. O navegador em segundo plano cria e o torna parte do padrão de especificação do CORS.
Quando essa chamada OPTIONS é feita, determinados valores precisam estar na resposta dessa chamada para que ela tenha êxito e para que a chamada HTTP real do recurso aconteça. Se a chamada OPTIONS falhar, o recurso não será recuperado e um erro de CORS deve aparecer no console do navegador. Anote se você vir uma chamada OPTIONS Anote também se você vir uma chamada de redirecionamento (status 302) acontecendo logo antes da chamada OPTIONS. Se um redirecionamento estiver acontecendo em uma chamada OPTIONS, esta provavelmente irá falhar. Isso significa que a chamada para obter o recurso também falhará e disparará um erro de CORS. - Qual é o caso de uso da obtenção de recursos externos?
Primeiro, descubra por que esse recurso externo está sendo recuperado. Isso pode ser importante para a criação de soluções alternativas ou necessárias. -
Gere um arquivo HAR.
Obter um instantâneo da falha da chamada e o que aconteceu imediatamente antes e depois pode ajudar a depurar o problema e evitar que o usuário precise reproduzi-lo. Os cabeçalhos de solicitações e respostas podem ser examinados, além da identificação de chamadas e redirecionamentos de OPÇÕES.
Próximas etapas possíveis
- Quem é o proprietário do servidor externo?
Access-Control-Allow-OriginTalvez o servidor possa ser modificado para aderir ao padrão de especificação CORS para retornar o cabeçalho. No entanto, lembre-se de que, mesmo que o servidor seja algo controlado internamente, isso não é necessariamente uma solução. Pode haver boas razões para que um serviço externo específico não queira compartilhar um recurso. Se o servidor externo não for algo controlado internamente, talvez trabalhe com esse fornecedor ou crie outra solução alternativa, supondo que o caso de uso seja considerado válido. -
O aplicativo foi criado usando a estrutura de aplicativos do Zendesk? Um servidor proxy de backend está disponível na chamada
client.request(). Usar este proxy definindocors:falsenas configurações de client.request. Observe que "false" também é o valor padrão da configuração. Como o serviço de proxy é um serviço de backend, ele não precisa aderir à especificação CORS do navegador, portanto, a chamada entre origens pode ter êxito usando o proxy.
Isso também nem sempre é uma solução para tudo. O serviço de proxy não oferece suporte à recuperação de arquivos ou informações binárias de serviços externos. Pode haver outros motivos específicos do aplicativo para que essa também não seja uma solução. - O recurso pode ser incorporado diretamente no aplicativo da web? Em vez de buscar um recurso entre origens, considere incluí-lo no aplicativo web. Isso evita completamente a chamada entre origens (como agora é um recurso local) e quaisquer problemas de CORS podem desaparecer. No entanto, isso nem sempre é uma correção. Às vezes, as URLs de recursos externos não são conhecidas antecipadamente, ou o recurso é muito grande para caber como recurso local ou o recurso muda frequentemente para baixá-lo como um recurso estático local.
- Qual é a versão do navegador? Apesar de a especificação do CORS ser um padrão, as mensagens de erro retornadas pelos navegadores podem ser diferentes. O Chrome retorna mensagens de console diferentes das do Firefox.
- Às vezes, não há nenhuma correção. Às vezes, uma solicitação de recurso de um serviço externo não deve ser compartilhada no contexto de um aplicativo da web do navegador. O responsável pelo recurso decide se ele compartilha ou não o recurso. Isso não depende do aplicativo da web. Ele pode ter sido desenvolvido assim.
Para obter mais informações, consulte estes artigos:
- Artigo da Wikipedia: Compartilhamento de recursos de origem cruzada
- Artigo de Web.Dev: Compartilhamento de recursos de origem cruzada (CORS)
- Artigo da Mozilla: Compartilhamento de recursos de origem cruzada (CORS)
- Artigo da Mozilla:
- Artigo da Fetch: Obter
- Artigo da Fetch: Protocolo CORS
0 comentários