A resposta à solicitação de comprovação não passa na verificação de controle de acesso

Estou recebendo este erro usando o ngResource para chamar uma API REST no Amazon Web Services:

XMLHttpRequest não pode carregar http://server.apiurl.com:8000/s/login?login=facebook . A resposta à solicitação de comprovação não passa na verificação do controle de acesso: Nenhum cabeçalho 'Access-Control-Allow-Origin' está presente no recurso solicitado. Portanto, a origem ' http: // localhost ' não é permitida. Erro 405

Serviço:

socialMarkt.factory('loginService', ['$resource', function($resource){    
    var apiAddress = "http://server.apiurl.com:8000/s/login/";
    return $resource(apiAddress, { login:"facebook", access_token: "@access_token" ,facebook_id: "@facebook_id" }, {
                getUser: {method:'POST'}
            });
}]);

Controlador:

[...]
loginService.getUser(JSON.stringify(fbObj)),
                function(data){
                    console.log(data);
                },
                function(result) {
                    console.error('Error', result.status);
                }
[...]

Estou usando o Chrome e não sei mais o que fazer para corrigir esse problema. Eu até configurei o servidor para aceitar cabeçalhos de origem localhost.

Você está tendo problemas com o CORS.

Existem várias maneiras de corrigir / solucionar isso.

1. Desligue o CORS. Por exemplo: como desativar cors no chrome
2. Use um plugin para o seu navegador
3. Use um proxy como o nginx. exemplo de como configurar
4. Siga a configuração necessária para o seu servidor. Esse é mais um fator do servidor da web que você carregou na instância do EC2 (presumindo que isso seja o que você quer dizer com "Amazon web service"). Para seu servidor específico, você pode consultar o site ativar o CORS.

Mais detalhadamente, você está tentando acessar api.serverurl.com a partir do localhost. Esta é a definição exata de solicitação entre domínios.

Ao desativá-lo apenas para concluir seu trabalho (OK, coloque pouca segurança para você se você visitar outros sites e apenas abrir a lata no caminho), você pode usar um proxy que faz o navegador pensar que todas as solicitações vêm do host local quando realmente você tem um servidor local que chama o servidor remoto.

portanto, api.serverurl.com pode se tornar localhost: 8000 / api e seu nginx local ou outro proxy será enviado para o destino correto.

Agora, por demanda popular, 100% mais informações sobre o CORS .... o mesmo bom gosto!

E para os que recusam ... ignorar o CORS é exatamente o que é mostrado para aqueles que simplesmente aprendem o front-end. https://codecraft.tv/courses/angular/http/http-with-promises/

Meu "API Server" é um aplicativo PHP. Para solucionar esse problema, encontrei a solução abaixo para funcionar:

Coloque as linhas em index.php

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS');
header('Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token');

Na API da web do AspNetCore, esse problema foi corrigido adicionando "Microsoft.AspNetCore.Cors" (versão 1.1.1) e adicionando as alterações abaixo no Startup.cs.

public void ConfigureServices(IServiceCollection services)
{ 
    services.AddCors(options =>
    {
          options.AddPolicy("AllowAllHeaders",
                builder =>
            {
                    builder.AllowAnyOrigin()
                           .AllowAnyHeader()
                           .AllowAnyMethod();
                });
    });
    .
    .
    .
}

e

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{


    // Shows UseCors with named policy.
    app.UseCors("AllowAllHeaders");
    .
    .
    .
}

e colocando [EnableCors("AllowAllHeaders")]o controlador.

Existem algumas advertências quando se trata de CORS. Primeiro, ele não permite curingas* mas não me prenda a isso. Eu li em algum lugar e não consigo encontrar o artigo agora.

Se você estiver solicitando um domínio diferente, precisará adicionar os cabeçalhos de origem permitida.

 Access-Control-Allow-Origin: www.other.com 

Se você está fazendo solicitações que afetam os recursos do servidor, como POST / PUT / PATCH, e se o tipo MIME é diferente do seguinte application/x-www-form-urlencoded, multipart/form-dataou text/plaino navegador irá automaticamente fazer uma pre-flight OPÇÕES solicitar para verificar com o servidor se ele permitiria .

Portanto, sua API / servidor precisa lidar com essas solicitações OPTIONS de acordo. Você precisa responder com o access control headerscódigo de status de resposta HTTP apropriado e deve ser200 .

Os cabeçalhos devem ser algo assim, ajuste-os de acordo com suas necessidades:

   Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
   Access-Control-Allow-Headers: Content-Type
   Access-Control-Max-Age: 86400

O cabeçalho de idade máxima é importante, no meu caso, não funcionaria sem ele, acho que o navegador precisa das informações por quanto tempo os "direitos de acesso" são válidos.

Além disso, se você estiver fazendo, por exemplo, uma POSTsolicitação com application/jsonmime de um domínio diferente, também precisará adicionar o cabeçalho de origem de permissão mencionado anteriormente, para que fique assim:

   Access-Control-Allow-Origin: www.other.com 
   Access-Control-Allow-Methods: GET, POST, PUT, PATCH, POST, DELETE, OPTIONS
   Access-Control-Allow-Headers: Content-Type
   Access-Control-Max-Age: 86400

Quando o pré-vôo for bem-sucedido e obtiver todas as informações necessárias, sua solicitação real será feita.

De um modo geral, quaisquer Access-Controlcabeçalhos solicitados na solicitação inicial ou pré-vôo devem ser fornecidos na resposta para que funcione.

Há um bom exemplo nos documentos MDN aqui neste link , e você também deve verificar esta postagem do SO

JavaScript XMLHttpRequest e Fetch seguem a política de mesma origem. Portanto, um aplicativo Web usando XMLHttpRequest ou Fetch pode fazer apenas solicitações HTTP para seu próprio domínio.

Fonte: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Você deve enviar o cabeçalho HTTP de Controle de Acesso-Permissão-Origem: * do lado do servidor.

Se você estiver usando o Apache como seu servidor HTTP, poderá adicioná-lo ao seu arquivo de configuração do Apache assim:

<IfModule mod_headers.c>
    Header set Access-Control-Allow-Origin "*"
</IfModule>

Mod_headers é ativado por padrão no Apache, no entanto, convém garantir que ele seja ativado executando:

 a2enmod headers

Se você está escrevendo uma extensão chrome

Você precisa adicionar manifest.jsonas permissões para seu (s) domínio (s).

"permissions": [
   "http://example.com/*",
   "https://example.com/*"
]

Se você estiver usando o servidor IIS por acaso. Você pode definir os cabeçalhos abaixo na opção Cabeçalhos de solicitação HTTP.

Access-Control-Allow-Origin:*
Access-Control-Allow-Methods: 'HEAD, GET, POST, PUT, PATCH, DELETE'
Access-Control-Allow-Headers: 'Origin, Content-Type, X-Auth-Token';

com tudo isso, receba etc., funcionará bem.

Para servidor de balão python, você pode usar o plug-in flask-cors para ativar solicitações de domínio cruzado.

Veja: https://flask-cors.readthedocs.io/en/latest/

No PHP você pode adicionar os cabeçalhos:

<?php
header ("Access-Control-Allow-Origin: *");
header ("Access-Control-Expose-Headers: Content-Length, X-JSON");
header ("Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE, OPTIONS");
header ("Access-Control-Allow-Headers: *");
...

Para corrigir problemas de solicitações de origem cruzada em um aplicativo Node JS:

npm i cors

E basta adicionar as linhas abaixo ao app.js

let cors = require('cors')
app.use(cors())

No meu arquivo de configuração do Apache VirtualHost, adicionei as seguintes linhas:

Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header always set Access-Control-Max-Age "1000"
Header always set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"

RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule ^(.*)$ $1 [R=200,L]

Para aqueles que estão usando o Lambda Integrated Proxy com API Gateway . Você precisa configurar sua função lambda como se estivesse enviando suas solicitações diretamente, o que significa que a função deve configurar os cabeçalhos de resposta corretamente. (Se você estiver usando funções lambda personalizadas, isso será tratado pelo API Gateway.)

//In your lambda's index.handler():
exports.handler = (event, context, callback) => {
     //on success:
     callback(null, {
           statusCode: 200,
           headers: {
                "Access-Control-Allow-Origin" : "*"
           }
     }
}

Eu acho que desabilitar o CORS do Chrome não é uma boa maneira , porque se você o estiver usando no iônico, certamente no Mobile Build a questão aumentará novamente.

Tão melhor para corrigir em seu back-end.

Antes de tudo No cabeçalho, você precisa definir

• cabeçalho ('Access-Control-Allow-Origin: *');
• header ('Header set Access-Control-Allow-Headers: "Origin, X-Requested With, Content-Type, Accept"');

E se a API estiver se comportando como GET e POST, ambos também serão definidos no cabeçalho -

if ($ _SERVER ['REQUEST_METHOD'] == 'OPÇÕES') {if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_METHOD']))) cabeçalho ("Métodos de permissão de controle de acesso: GET, POST, OPTIONS");
if (isset ($ _ SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) cabeçalho ("Acesso-Controle-Permitir Cabeçalhos:
{$ _SERVER ['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']}"); saída (0); }

Uma causa muito comum desse erro pode ser que a API do host tenha mapeado a solicitação para um método http (por exemplo, PUT) e o cliente da API esteja chamando a API usando um método http diferente (por exemplo, POST ou GET)

Nossa equipe ocasionalmente vê isso usando Vue, axios e um C # WebApi. Adicionar um atributo de rota no terminal que você está tentando acessar o corrige.

[Route("ControllerName/Endpoint")]
[HttpOptions, HttpPost]
public IHttpActionResult Endpoint() { }

Eu enfrentei esse problema quando o servidor DNS foi definido como 8.8.8.8 (google). Na verdade, o problema estava no roteador, meu aplicativo tentou se conectar ao servidor pelo google, não localmente (no meu caso particular). Eu removi o 8.8.8.8 e isso resolveu o problema. Sei que esses problemas foram resolvidos pelas configurações do CORS, mas talvez alguém tenha o mesmo problema que eu

Estou usando o AWS sdk para uploads, depois de passar algum tempo pesquisando on-line, me deparei com esse tópico. Graças a @lsimoneau 45581857 , acontece exatamente o mesmo que estava acontecendo. Simplesmente apontei meu URL de solicitação para a região no meu bucket anexando a opção region e funcionou.

 const s3 = new AWS.S3({
 accessKeyId: config.awsAccessKeyID,
 secretAccessKey: config.awsSecretAccessKey,
 region: 'eu-west-2'  // add region here });

As distribuições independentes do GeoServer incluem o servidor de aplicativos Jetty. Ative o compartilhamento de recursos de origem cruzada (CORS) para permitir que aplicativos JavaScript fora do seu domínio usem o GeoServer.

Remova o comentário do seguinte <filter>e <filter-mapping>de webapps / geoserver / WEB-INF / web.xml:

<web-app>
  <filter>
      <filter-name>cross-origin</filter-name>
      <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class>
  </filter>
  <filter-mapping>
      <filter-name>cross-origin</filter-name>
      <url-pattern>/*</url-pattern>
  </filter-mapping>
</web-app>

É fácil resolver esse problema com apenas algumas etapas, sem se preocupar com nada. Por favor, siga os passos para resolvê-lo.

1. open ( https://www.npmjs.com/package/cors#enabling-cors-pre-flight )
2. vá para instalação e copie o comando npm install cors para instalar via terminal do nó
3. vá para Uso Simples (Ativar Todas as Solicitações do CORS) rolando. em seguida, copie e cole a declaração completa no seu projeto e execute-a ... isso funcionará com certeza .. copie o código do comentário e cole-o no app.js ou em qualquer outro projeto e tente ...

Algo que é muito fácil de perder ...

No Solution Explorer, clique com o botão direito do mouse em api-project. Na janela de propriedades, defina 'Autenticação Anônima' como Ativado !!!

Desabilite a segurança do Chrome. Crie um atalho do Chrome com o botão direito do mouse -> propriedades -> destino, cole este "C: \ Arquivos de Programas (x86) \ Google \ Chrome \ Application \ chrome.exe" --disable-web-security --user -data-dir = "c: / chromedev"