Por que meu JavaScript obtém um erro “No ‘Access-Control-Allow-Origin’ está presente no recurso solicitado” quando o Postman não?

Eu estou tentando fazer autorização usando JavaScript conectando-se à API RESTful construída no Flask . No entanto, quando faço a solicitação, recebo o seguinte erro:

XMLHttpRequest não pode carregar http: // myApiUrl / login . Nenhum header ‘Access-Control-Allow-Origin’ está presente no recurso solicitado. A origem ‘null’ não tem, portanto, permissão de access.

Eu sei que a API ou recurso remoto deve definir o header, mas por que funcionou quando fiz a solicitação por meio da extensão do Chrome Postman ?

Este é o código de solicitação:

$.ajax({ type: "POST", dataType: 'text', url: api, username: 'user', password: 'pass', crossDomain : true, xhrFields: { withCredentials: true } }) .done(function( data ) { console.log("done"); }) .fail( function(xhr, textStatus, errorThrown) { alert(xhr.responseText); alert(textStatus); }); 

   

    Se eu entendi direito você está fazendo um XMLHttpRequest para um domínio diferente do que sua página está. Portanto, o navegador está bloqueando isso, pois normalmente permite uma solicitação na mesma origem por motivos de segurança. Você precisa fazer algo diferente quando quiser fazer uma solicitação entre domínios. Um tutorial sobre como conseguir isso é usando o CORS .

    Quando você está usando carteiro eles não são restritos por esta política. Citado de XMLHttpRequest de origem cruzada :

    Páginas web regulares podem usar o object XMLHttpRequest para enviar e receber dados de servidores remotos, mas eles são limitados pela mesma política de origem. Extensões não são tão limitadas. Uma extensão pode falar com servidores remotos fora de sua origem, desde que primeiro solicite permissions de origem cruzada.

    Isso não é uma correção para produção ou quando o aplicativo precisa ser mostrado para o cliente, isso só é útil quando o desenvolvimento da UI e do Backend estão em servidores diferentes e na produção eles estão, na verdade, no mesmo servidor. Por exemplo: Ao desenvolver a interface do usuário para qualquer aplicativo, se houver necessidade de testá-lo localmente, apontando-o para o servidor de back-end, nesse cenário, essa é a correção perfeita. Para correção de produção, os headers CORS devem ser adicionados ao servidor backend para permitir access de origem cruzada.

    A maneira mais fácil é simplesmente adicionar a extensão no Google Chrome para permitir o access usando o CORS.

    ( https://chrome.google.com/webstore/detail/allow-control-allow-origi/nlfbmbojpeacfghkpbjhddihlkkiljbi?hl=pt-BR )

    Basta ativar essa extensão sempre que você quiser permitir access a nenhuma solicitação de header ‘access-control-allow-origin’ .

    Ou

    No Windows, cole este comando na janela de execução

     chrome.exe --user-data-dir="C:/Chrome dev session" --disable-web-security 

    isso abrirá um novo navegador chrome que permite o access a nenhuma solicitação de header ‘access-control-allow-origin’ .

    Se você puder lidar com JSON em troca, tente usar JSONP (observe o P no final) para falar entre domínios:

     $.ajax({ type: "POST", dataType: 'jsonp', ...... etc ...... 

    Saiba mais sobre como trabalhar com o JSONP aqui :

    O advento do JSONP – essencialmente um hack consensual de scripts entre sites – abriu a porta para poderosos mashups de conteúdo. Muitos sites proeminentes fornecem serviços JSONP, permitindo access ao conteúdo por meio de uma API predefinida.

    É muito simples de resolver se você estiver usando PHP . Basta adicionar o seguinte script no início da sua página PHP, que trata da solicitação:

     < ?php header('Access-Control-Allow-Origin: *'); ?> 

    Aviso: Isso contém um problema de segurança para o arquivo PHP que pode ser chamado por invasores. você tem que usar sessões e cookies para autenticação para prevenir seu arquivo / serviço contra este ataque. Seu serviço é vulnerável a falsificação de solicitações entre sites (CSRF).

    Se você estiver usando o Node-red , deverá permitir o CORS no arquivo node-red/settings.js , deixando de comentar as seguintes linhas:

     // The following property can be used to configure cross-origin resource sharing // in the HTTP nodes. // See https://github.com/troygoode/node-cors#configuration-options for // details on its contents. The following is a basic permissive set of options: httpNodeCors: { origin: "*", methods: "GET,PUT,POST,DELETE" }, 

    Eu gostaria que alguém compartilhasse este site comigo há muito tempo http://cors.io/ teria economizado muito tempo comparado a construir e confiar em meu próprio proxy. No entanto, à medida que você passa para a produção, ter sua própria proxy é a melhor opção, pois você ainda controla todos os aspectos de seus dados.

    Tudo que você precisa:

    https://cors.io/?http://HTTP_YOUR_LINK_HERE

    Há um problema de vários domínios usando o Ajax. Você deve ter certeza de que está acessando seus arquivos no mesmo caminho http:// sem www. (ou aceda a partir de http://www. e publique para o mesmo caminho, incluindo www. ) que o browser considera como outro domínio quando acede a um www. caminho, então você vê onde está o problema. Você está postando em um domínio diferente e o navegador bloqueia o stream devido ao problema de origem.

    Se a API não for colocada no mesmo host do qual você está solicitando, o stream será bloqueado e você precisará encontrar outra maneira de se comunicar com a API.

    Se você estiver usando o Node.js , tente:

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

    Mais informações: CORS no ExpressJS

    Porque
    $ .ajax ({type: “POST”OPÇÕES DE CHAMADAS
    $ .post ( – chama o POST

    ambos são diferentes Carteiro chama “POST” corretamente, mas quando nós o chamamos será “OPÇÕES”

    Para c # web services – webapi

    Por favor, adicione o seguinte código no seu arquivo web.config sob a tag . Isso vai funcionar

          

    Por favor, verifique se você não está cometendo nenhum erro na chamada ajax

    jQuery

     $.ajax({ url: 'http://mysite.microsoft.sample.xyz.com/api/mycall', headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, type: "POST", /* or type:"GET" or type:"PUT" */ dataType: "json", data: { }, success: function (result) { console.log(result); }, error: function () { console.log("error"); } }); 

    Angular 4 questão por favor consulte: http://www.hubfly.com/blog/solutions/how-to-fix-angular-4-api-call-issues/

    Nota: Se você estiver procurando por download de conteúdo de sites de terceiros , isso não ajudará você . Você pode tentar o seguinte código, mas não o JavaScript.

     System.Net.WebClient wc = new System.Net.WebClient(); string str = wc.DownloadString("http://mysite.microsoft.sample.xyz.com/api/mycall"); 

    Tente XDomain ,

    Resumo: Uma alternativa pura de puro CORS / polyfill. Nenhuma configuração de servidor é necessária – basta adicionar um proxy.html no domínio com o qual você deseja se comunicar. Esta biblioteca usa o XHook para conectar todos os XHR , então o XDomain deve funcionar em conjunto com qualquer biblioteca.

    Se você não quiser:

    1. Desativar segurança da Web no Chrome
    2. Use JSONP
    3. Use um site de terceiros para redirect suas solicitações

    e você tem certeza de que seu servidor tem o CORS ativado (teste o CORS aqui: http://www.test-cors.org/ )

    Então você precisa passar no parâmetro de origem com o seu pedido. Esta origem DEVE corresponder à origem que o seu navegador envia com o seu pedido.

    Você pode vê-lo em ação aqui: http://www.wikibackpacker.com/app/detail/Campgrounds/3591

    A funcionalidade de edição envia uma solicitação GET & POST para um domínio diferente para buscar dados. Eu defino o parâmetro de origem que resolve o problema. O backend é um mecanismo do mediaWiki.

    tldr: Adicione o parâmetro “origin” às suas chamadas, que deve ser o parâmetro Origin que o seu navegador envia (você não pode falsificar o parâmetro de origem)

    Eu tive um problema com isso quando usei o AngularJS para acessar minha API. A mesma solicitação funcionou no SoapUI 5.0 e no ColdFusion. Meu método GET já tinha o header Access-Control-Allow-Origin.

    Descobri que o AngularJS faz uma solicitação “trial” de OPTIONS . O ColdFusion, por padrão, gera o método OPTIONS, mas não tem muito, especificamente esses headers. O erro foi gerado em resposta a essa chamada OPTIONS e não a minha chamada intencional para GET. Depois que adicionei o método OPTIONS abaixo à minha API, o problema foi resolvido.

           

    Eu tive a seguinte configuração, resultando no mesmo erro, ao solicitar respostas do servidor.

    Do lado do servidor: SparkJava -> fornece a API REST
    Lado do cliente: ExtJs6 -> fornece renderização do navegador

    No lado do servidor eu tive que adicionar isso à resposta:

     Spark.get("/someRestCallToSpark", (req, res) -> { res.header("Access-Control-Allow-Origin", "*"); //important, otherwise its not working return "some text"; }); 

    No lado do cliente eu tive que adicionar isso ao pedido:

     Ext.Ajax.request({ url: "http://localhost:4567/someRestCallToSpark", useDefaultXhrHeader: false, //important, otherwise its not working success: function(response, opts) {console.log("success")}, failure: function(response, opts) {console.log("failure")} }); 

    Com base na resposta de shruti , criei um atalho do navegador Chrome com os argumentos necessários: insira a descrição da imagem aqui insira a descrição da imagem aqui

    Você pode contornar o problema usando o YQL para fazer proxy do pedido através dos servidores do Yahoo. São apenas algumas linhas de código:

     var yql_url = 'https://query.yahooapis.com/v1/public/yql'; var url = 'your api url'; $.ajax({ 'url': yql_url, 'data': { 'q': 'SELECT * FROM json WHERE url="'+url+'"', 'format': 'json', 'jsonCompat': 'new', }, 'dataType': 'jsonp', 'success': function(response) { console.log(response); }, }); 

    Aqui está o link com uma explicação: https://vverma.net/fetch-any-json-using-jsonp-and-yql.html

    https://github.com/Rob–W/cors-anywhere/ fornece o código (Node.js) que você pode usar para configurar e executar seu próprio proxy CORS. Ele é mantido ativamente e fornece vários resources para controlar o comportamento do proxy além do envio básico dos headers de resposta Access-Control-* corretos.

    https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Access_control_CORS tem detalhes para explicar como os navegadores lidam com solicitações de origem cruzada feitas por aplicativos da Web do lado do cliente a partir de JavaScript e quais headers você deve configurar para enviar por o servidor a solicitação é feita, se você puder.

    No caso em que um site para o qual você precisa fazer uma solicitação e obter uma resposta não retorna o header de resposta Access-Control-Allow-Origin , os navegadores sempre bloquearão as solicitações de origem cruzada feitas diretamente pelo seu cliente lado-código JavaScript de trabalhar. E assim, se o site não é um que você controla e pode configurar o comportamento, a única coisa que funcionará nesse caso é fazer o proxy das solicitações – por meio de seu próprio proxy executado por você ou por meio de um proxy aberto.

    Como mencionado em outros comentários aqui, há boas razões para não confiar em um proxy aberto com suas solicitações. Dito isso, se você sabe o que está fazendo e decide que um proxy aberto funciona para as suas necessidades, https://cors-anywhere.herokuapp.com/ é um que está disponível de forma confiável, mantido ativamente e que executa uma instância do https://github.com/Rob–W/cors-anywhere/ code.

    Tal como acontece com outros proxies abertos mencionados aqui (alguns dos quais, pelo menos, não parecem estar disponíveis por mais tempo), a forma como funciona é que, em vez de ter o seu código de cliente enviar um pedido diretamente para, por exemplo, http://foo.com você envia para https://cors-anywhere.herokuapp.com/http://foo.com e o proxy adiciona os headers necessários do Access-Control-* à resposta que o navegador vê.

    Se você estiver usando o Entity Framework , parece que esse erro algumas vezes será lançado mesmo se você tiver o CORS habilitado. Eu descobri que o erro ocorreu devido a uma falta de finalização da consulta. Espero que isso ajude os outros na mesma situação.

    O seguinte código pode lançar o XMLHttpRequest cannot load http://myApiUrl/login. No 'Access-Control-Allow-Origin' header is present on the requested resource. XMLHttpRequest cannot load http://myApiUrl/login. No 'Access-Control-Allow-Origin' header is present on the requested resource. erro:

     using (DBContext db = new DBContext()) { return db.Customers.Select(x => new { Name = x.Name, CustomerId = x.CustomerId, }); } 

    Para corrigi-lo, uma chamada de finalização como .ToList() ou .FirstOrDefault() no final da consulta é necessária, assim:

     using (DBContext db = new DBContext()) { return db.Customers.Select(x => new { Name = x.Name, CustomerId = x.CustomerId, }).ToList(); } 

    No meu caso eu estava usando o aplicativo JEE7 JAX-RS e seguir os truques funcionou perfeitamente para mim:

     @GET @Path("{id}") public Response getEventData(@PathParam("id") String id) throws FileNotFoundException { InputStream inputStream = getClass().getClassLoader().getResourceAsStream("/eventdata/" + id + ".json"); JsonReader jsonReader = Json.createReader(inputStream); return Response.ok(jsonReader.readObject()).header("Access-Control-Allow-Origin", "*").build(); } 

    Se você receber essa mensagem de erro do navegador:

     No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '…' is therefore not allowed access 

    Quando você está tentando fazer um pedido Ajax POST / GET para um servidor remoto que está fora de seu controle, por favor, esqueça esta simples correção:

     < ?php header('Access-Control-Allow-Origin: *'); ?> 

    Você realmente precisa, especialmente se você usa JavaScript apenas para fazer o pedido Ajax, um proxy interno que recebe sua consulta e a envia para o servidor remoto.

    Primeiro no seu código JavaScript, faça uma chamada Ajax para seu próprio servidor, algo como:

     $.ajax({ url: yourserver.com/controller/proxy.php, async: false, type: "POST", dataType: "json", data: data, success: function (result) { JSON.parse(result); }, error: function (xhr, ajaxOptions, thrownError) { console.log(xhr); } }); 

    Em seguida, crie um arquivo PHP simples chamado proxy.php para agrupar seus dados POST e anexá-los ao servidor de URL remoto como parâmetros. Dou-lhe um exemplo de como contornei esse problema com a API de pesquisa do Expedia Hotel:

     if (isset($_POST)) { $apiKey = $_POST['apiKey']; $cid = $_POST['cid']; $minorRev = 99; $url = 'http://api.ean.com/ean-services/rs/hotel/v3/list?' . 'cid='. $cid . '&' . 'minorRev=' . $minorRev . '&' . 'apiKey=' . $apiKey; echo json_encode(file_get_contents($url)); } 

    Fazendo:

     echo json_encode(file_get_contents($url)); 

    Você está apenas fazendo a mesma consulta, mas no lado do servidor e depois disso, ele deve funcionar bem.

    Resposta copiada e colada do NizarBsb

    Consegui resolver com sucesso (no meu caso, para fonts) usando o htaccess, mas, obviamente, OP está pedindo pouco diferente. Mas você pode usar o padrão FileMatch e adicionar qualquer tipo de extensão para que não ocorra erro.

       Header set Access-Control-Allow-Origin "*"   

    https://httpd.apache.org/docs/2.4/mod/core.html#filesmatch

    Pergunta popular – Outra coisa para ver se você leu até aqui e nada mais ajudou. Se você tiver um CDN como Akamai, Limelight ou similar, poderá verificar a chave de cache que você possui para o URI do recurso. Se não include o valor do header Origem, você poderá retornar uma resposta armazenada em cache quando solicitada de outra Origem. Acabamos de passar meio dia depurando isso. A configuração do CDN foi atualizada para include apenas o valor de Origem para alguns domínios selecionados que são nossos e configurá-lo como null para todos os outros. Isso parece funcionar e permite que navegadores de nossos domínios conhecidos visualizem nossos resources. Certamente todas as outras respostas são pré-requisitos para chegar aqui, mas se o CDN é o primeiro salto do seu navegador, isso é algo para rever.

    No nosso caso, pudemos ver alguns pedidos chegando ao nosso serviço, mas não quase o volume que o site estava enviando. Isso nos indicou o CDN. Conseguimos voltar e ver que a solicitação original foi atendida por uma solicitação direta, não como parte de uma chamada AJAX do navegador, e o header de resposta Access-Control-Allow-Origin não foi incluído. Aparentemente, o CDN armazenou esse valor em cache. O ajuste da configuração da CDN da Akamai para considerar o valor do header da solicitação de origem como parte da correspondência parece ter feito isso funcionar para nós.

    Para a API do GoLang:

    Primeiro você pode dar uma olhada no MDN CORS Doc para saber o que é o CORS. Até onde eu sei, o CORS é sobre permitir que o Origin Of Request acesse ou não o Recurso do Servidor.

    E você pode restringir qual origem da solicitação pode acessar o servidor definindo Access-Control-Allow-Origin no Header da resposta do servidor.

    Por exemplo, definir o seguinte header na resposta do servidor significa que apenas a solicitação enviada de http://foo.example pode acessar seu servidor:

     Access-Control-Allow-Origin: http://foo.example 

    e seguindo pedido de permissão enviado de qualquer origem (ou domínio):

     Access-Control-Allow-Origin: * 

    E como eu sei na mensagem de erro, requested resource significa recurso do servidor, portanto, No 'Access-Control-Allow-Origin' header is present on the requested resource. significa que você não definiu o header Access-Control-Allow-Origin em sua resposta do servidor, ou talvez você definiu, mas a origem da solicitação não está listada em Access-Control-Allow-Origin portanto a solicitação não tem permissão de access:

    Nenhum header ‘Access-Control-Allow-Origin’ está presente no recurso solicitado. A origem ‘null’ não tem, portanto, permissão de access.

    No GoLang, eu uso o pacote gorilla/mux para construir o servidor de API no localhost:9091 , e permito que o CORS adicione "Access-Control-Allow-Origin", "*" ao header da resposta:

     func main() { // API Server Code router := mux.NewRouter() // API route is /people, //Methods("GET", "OPTIONS") means it support GET, OPTIONS router.HandleFunc("/people", GetPeople).Methods("GET", "OPTIONS") log.Fatal(http.ListenAndServe(":9091", router)) } // Method of '/people' route func GetPeople(w http.ResponseWriter, r *http.Request) { // Allow CORS by setting * in sever response w.Header().Set("Access-Control-Allow-Origin", "*") w.Header().Set("Access-Control-Allow-Headers", "Content-Type") json.NewEncoder(w).Encode("OKOK") } 

    E eu uso JavaScript no cliente, em localhost:9092 fazer pedido pelo Chrome pode obter com êxito “OKOK” do servidor localhost:9091 .

     function GetPeople() { try { var xhttp = new XMLHttpRequest(); xhttp.open("GET", "http://localhost:9091/people", false); xhttp.setRequestHeader("Content-type", "text/html"); xhttp.send(); var response = JSON.parse(xhttp.response); alert(xhttp.response); } catch (error) { alert(error.message); } } 

    Além disso, você pode verificar seu header de solicitação / resposta usando ferramentas como o Fiddler .

    A lot of times this happens to me from javascript to my php api, because one of a few reasons. I forget to put the < ?php header('Access-Control-Allow-Origin: *'); ? is one. This is helpful for cross sub domain access. Another reason, is because in jQuery ajax request I am specifying a specific dataType and returning a different dataType, so it throws an error.

    The Last and most prominent reasoning for this error is there is a parse error on the page you are requesting. If you hit that page url in your browser than more than likely you will see a parse error and you will have a line number to address the issue.

    Espero que isso ajude alguém. It took me a while each time to debug this and I wish I had a checklist of things to verify.

    I got this error with $http.get in Angular. I needed to use $http.jsonp instead.

    CORS is for you.

    CORS is “Cross Origin Resource Sharing” and is a way to send a cross-domain request. Now the XMLHttpRequest2 and Fetch API both support CORS.

    But it has its limits. Server need to specific claim the Access-Control-Allow-Origin , and it can not be set to ‘*’.

    And if you want any origin can send request to you, you need JSONP (also need to set Access-Control-Allow-Origin , but can be ‘*’).

    For lots of request way if you don’t know what to choose, I think you need a fully functional component to do that. Let me introduce a simple component catta


    If you are using a modern browser (> Internet Explorer9, Chrome, Firefox, Edge, etc.), it is very recommended you use a simple, but beautiful component, https://github.com/Joker-Jelly/catta . It has no dependencies, is less than 3 KB, and it supports Fetch, Ajax and JSONP with same dead-simple syntax and options.

     catta('./data/simple.json').then(function (res) { console.log(res); }); 

    It also supports all the way to import to your project, like ES6 module, CommonJS and even in HTML.

    Most of these answers tell users how to add CORS headers to a server they control.

    However, if you need data from a server you don’t control in a webpage, one solution is to create a script tag on your page, set the src attribute to the api endpoint that doesn’t have CORS headers, then load that data onto the page:

     window.handleData = function(data) { console.log(data) }; var script = document.createElement('script'); script.setAttribute('src','https://some.api/without/cors/headers.com&callback=handleData'); document.body.appendChild(script); 

    On my website (based on .NET) I’ve just added this:

              

    Big thanks to this video.

    For Ruby on Rails server in application_controller.rb , add this:

     after_action :cors_set_access_control_headers def cors_set_access_control_headers headers['Access-Control-Allow-Origin'] = '*' headers['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS' headers['Access-Control-Allow-Headers'] = '*' end 

    Nenhum header ‘Access-Control-Allow-Origin’ está presente no recurso solicitado. Origin ‘ https://sx.xyz.com ‘ is therefore not allowed access.

    I had also faced a similar problem with Cross Domain Data Exchange in the Ajax response as error undefined . But the response in header was Status Code:200 OK

     Failed to load https://www.Domain.in/index.php?route=api/synchronization/checkapikey: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://sx.xyz.in' is therefore not allowed access. 

    The solution to get around it: In my case it was to call the function checkapikey() via Ajax to another domain and get the response with data to where the call has been made:

     if (($this->request->server['REQUEST_METHOD'] == 'POST') && isset($this->request->server['HTTP_ORIGIN'])) { $this->response->addHeader('Access-Control-Allow-Origin: ' . $this->request->server['HTTP_ORIGIN']); $this->response->addHeader('Access-Control-Allow-Methods: GET, PUT, POST, DELETE, OPTIONS'); $this->response->addHeader('Access-Control-Max-Age: 1000'); $this->response->addHeader('Access-Control-Allow-Credentials: true'); $this->response->addHeader('Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With'); $headers = getallheaders(); ... } 

    Maybe is it a litte bit complicated but you can use a web server to route the request. With nodejs you havent this problem. I am not an expert in node js. So i dont know if this is clean code.

    But this works for me

    Here is a little exmaple:

    NODE JS

     var rp = require('request-promise'); var express = require('express'), app = express(), port = process.env.PORT || 3000; var options = { method: 'POST', uri: 'http://api.posttestserver.com/post', body: { some: 'payload' }, json: true // Automatically stringifies the body to JSON }; app.get('/', function (req, res) { rp(options) .then(function (parsedBody) { res.send(parsedBody) }) .catch(function (err) { res.send(err) }); }); app.listen(port); 

    JS

     axios.get("http://localhost:3000/").then((res)=>{ console.log('================res===================='); console.log(res); console.log('===================================='); }) 

    For Opera (it works the same as Chrome ), I started the browser with this command:

     opera --user-data-dir="~/Downloads/opera-session" --disable-web-security 

    The problem is solved! Now I can work on a local HTML file (on my hard disk drive) and call Ajax requests to remote origins in the same file.

    Note 1: You can give any folder in your home directory as –user-data-dir.

    Note 2: Tested on Debian 8 (Jessie)/Opera 39

    Aqui está uma captura de tela

    When you start normally (without the parameters above), the same request falls into the error code block.