AngularJS executa uma solicitação HTTP OPTIONS para um recurso de origem cruzada

Estou tentando configurar o AngularJS para se comunicar com um recurso de origem cruzada, onde o host do recurso que entrega meus arquivos de modelo está em um domínio diferente e, portanto, a solicitação XHR que o angular executa deve ser de domínio cruzado. Eu adicionei o cabeçalho CORS apropriado ao meu servidor para a solicitação HTTP para fazer isso funcionar, mas parece não funcionar. O problema é que, quando inspeciono as solicitações HTTP no meu navegador (chrome), a solicitação enviada ao arquivo do ativo é uma solicitação OPTIONS (deve ser uma solicitação GET).

Não tenho certeza se isso é um bug no AngularJS ou se preciso configurar alguma coisa. Pelo que entendi, o wrapper XHR não pode fazer uma solicitação HTTP OPTIONS, portanto, parece que o navegador está tentando descobrir se é "permitido" fazer o download do ativo primeiro antes de executar a solicitação GET. Se for esse o caso, também preciso definir o cabeçalho CORS (Access-Control-Allow-Origin: http://asset.host ... ) Com o host do recurso também?

A solicitação OPTIONS não é de forma alguma um bug do AngularJS; é assim que o padrão de compartilhamento de recursos entre origens exige que os navegadores se comportem. Consulte este documento: https://developer.mozilla.org/en-US/docs/HTTP_access_control , onde na seção "Visão geral" diz:

O padrão de compartilhamento de recursos de origem cruzada funciona adicionando novos cabeçalhos HTTP que permitem aos servidores descrever o conjunto de origens que têm permissão para ler essas informações usando um navegador da web. Além disso, para métodos de solicitação HTTP que podem causar efeitos colaterais nos dados do usuário (em particular; para métodos HTTP diferentes de GET ou para uso do POST com certos tipos MIME). A especificação exige que os navegadores "preflight" a solicitação, solicitando métodos suportados do servidor com um cabeçalho de solicitação HTTP OPTIONS e, em seguida, mediante "aprovação" do servidor, enviando a solicitação real com o método de solicitação HTTP real. Os servidores também podem notificar os clientes se "credenciais" (incluindo dados de autenticação HTTP e cookies) devem ser enviadas com solicitações.

É muito difícil fornecer uma solução genérica que funcione para todos os servidores da WWW, pois a instalação varia dependendo do servidor e dos verbos HTTP aos quais você pretende oferecer suporte. Gostaria de encorajar você a superar este excelente artigo ( http://www.html5rocks.com/en/tutorials/cors/ ) que tem muito mais detalhes sobre os cabeçalhos exatos que precisam ser enviados por um servidor.

Para o Angular 1.2.0rc1 +, você precisa adicionar uma resourceUrlWhitelist.

1.2: versão de lançamento, eles adicionaram uma função escapeForRegexp para que você não precise mais escapar das strings. Você pode adicionar o URL diretamente

'http://sub*.assets.example.com/**' 

certifique-se de adicionar ** para subpastas. Aqui está um jsbin funcional para 1.2: http://jsbin.com/olavok/145/edit

1.2.0rc: se você ainda estiver em uma versão rc, o Angular 1.2.0rc1 será a solução:

.config(['$sceDelegateProvider', function($sceDelegateProvider) {
     $sceDelegateProvider.resourceUrlWhitelist(['self', /^https?:\/\/(cdn\.)?yourdomain.com/]);
 }])

Aqui está um exemplo de jsbin em que funciona para 1.2.0rc1: http://jsbin.com/olavok/144/edit

Pré 1.2: Para versões mais antigas (ref http://better-inter.net/enabling-cors-in-angular-js/ ), você precisa adicionar as 2 linhas a seguir à sua configuração:

$httpProvider.defaults.useXDomain = true;
delete $httpProvider.defaults.headers.common['X-Requested-With'];

Aqui está um exemplo do jsbin em que funciona nas versões anteriores à 1.2: http://jsbin.com/olavok/11/edit

NOTA: Não tenho certeza se funciona com a versão mais recente do Angular.

ORIGINAL:

Também é possível substituir a solicitação OPTIONS (foi testada apenas no Chrome):

app.config(['$httpProvider', function ($httpProvider) {
  //Reset headers to avoid OPTIONS request (aka preflight)
  $httpProvider.defaults.headers.common = {};
  $httpProvider.defaults.headers.post = {};
  $httpProvider.defaults.headers.put = {};
  $httpProvider.defaults.headers.patch = {};
}]);

Seu serviço deve responder a uma OPTIONSsolicitação com cabeçalhos como estes:

Access-Control-Allow-Origin: [the same origin from the request]
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: [the same ACCESS-CONTROL-REQUEST-HEADERS from request]

Aqui está um bom documento: http://www.html5rocks.com/en/tutorials/cors/#toc-adding-cors-support-to-the-server

O mesmo documento diz

Diferentemente das solicitações simples (discutidas acima), as solicitações "preflighted" primeiro enviam um cabeçalho de solicitação HTTP OPTIONS para o recurso no outro domínio, para determinar se a solicitação real é segura para enviar. As solicitações entre sites são comprovadas dessa maneira, pois podem ter implicações nos dados do usuário. Em particular, um pedido é comprovado se:

Ele usa métodos diferentes de GET ou POST. Além disso, se o POST for usado para enviar dados da solicitação com um Tipo de Conteúdo diferente de application / x-www-form-urlencoded, multipart / form-data ou text / plain, por exemplo, se a solicitação POST enviar uma carga XML para o servidor usando application / xml ou text / xml, a solicitação é comprovada.

Ele define cabeçalhos personalizados na solicitação (por exemplo, a solicitação usa um cabeçalho como X-PINGOTHER)

Quando a solicitação original é Obter sem cabeçalhos personalizados, o navegador não deve fazer a solicitação de Opções, como faz agora. O problema é que ele gera um cabeçalho X-Requested-With que força a solicitação de Opções. Consulte https://github.com/angular/angular.js/pull/1454 sobre como remover este cabeçalho

Isso corrigiu meu problema:

$http.defaults.headers.post["Content-Type"] = "text/plain";

Se você estiver usando um servidor nodeJS, poderá usar esta biblioteca, ela funcionou bem para mim https://github.com/expressjs/cors

var express = require('express')
  , cors = require('cors')
  , app = express();

app.use(cors());

e depois que você pode fazer um npm update.

Aqui está a maneira como eu corrigi esse problema no ASP.NET

• Primeiro, você deve adicionar o pacote de pepitas Microsoft.AspNet.WebApi.Cors

• Em seguida, modifique o arquivo App_Start \ WebApiConfig.cs

  public static class WebApiConfig    
  {
     public static void Register(HttpConfiguration config)
     {
        config.EnableCors();
  
        ...
     }    
  }

• Adicione este atributo à sua classe de controlador

  [EnableCors(origins: "*", headers: "*", methods: "*")]
  public class MyController : ApiController
  {  
      [AcceptVerbs("POST")]
      public IHttpActionResult Post([FromBody]YourDataType data)
      {
           ...
           return Ok(result);
      }
  }

• Consegui enviar json para a ação dessa maneira

  $http({
          method: 'POST',
          data: JSON.stringify(data),
          url: 'actionurl',
          headers: {
              'Content-Type': 'application/json; charset=UTF-8'
          }
      }).then(...)

Referência: Habilitando solicitações de origem cruzada na API da Web do ASP.NET 2

De alguma forma eu consertei mudando

<add name="Access-Control-Allow-Headers" 
     value="Origin, X-Requested-With, Content-Type, Accept, Authorization" 
     />

para

<add name="Access-Control-Allow-Headers" 
     value="Origin, Content-Type, Accept, Authorization" 
     />

Perfeitamente descrito no comentário de pkozlowski. Eu tinha uma solução funcional com o AngularJS 1.2.6 e o ​​ASP.NET Web Api, mas quando eu atualizei o AngularJS para 1.3.3, as solicitações falharam.

• A solução para o servidor Web API foi adicionar o tratamento das solicitações OPTIONS no início do método de configuração (mais informações nesta postagem do blog ):

  app.Use(async (context, next) =>
  {
      IOwinRequest req = context.Request;
      IOwinResponse res = context.Response;
      if (req.Path.StartsWithSegments(new PathString("/Token")))
      {
          var origin = req.Headers.Get("Origin");
          if (!string.IsNullOrEmpty(origin))
          {
              res.Headers.Set("Access-Control-Allow-Origin", origin);
          }
          if (req.Method == "OPTIONS")
          {
              res.StatusCode = 200;
              res.Headers.AppendCommaSeparatedValues("Access-Control-Allow-Methods", "GET", "POST");
              res.Headers.AppendCommaSeparatedValues("Access-Control-Allow-Headers", "authorization", "content-type");
              return;
          }
      }
      await next();
  });

Se você estiver usando as APIs Jersey for REST, poderá fazer o seguinte

Você não precisa alterar sua implementação de serviços da web.

Vou explicar para o Jersey 2.x

1) Primeiro adicione um ResponseFilter como mostrado abaixo

import java.io.IOException;

import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerResponseContext;
import javax.ws.rs.container.ContainerResponseFilter;

public class CorsResponseFilter implements ContainerResponseFilter {

@Override
public void filter(ContainerRequestContext requestContext,   ContainerResponseContext responseContext)
    throws IOException {
        responseContext.getHeaders().add("Access-Control-Allow-Origin","*");
        responseContext.getHeaders().add("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT");

  }
}

2) no web.xml, na declaração de servlet de jersey, adicione o seguinte

    <init-param>
        <param-name>jersey.config.server.provider.classnames</param-name>
        <param-value>YOUR PACKAGE.CorsResponseFilter</param-value>
    </init-param>

Desisti de tentar corrigir esse problema.

Meu web.config do IIS tinha o "Access-Control-Allow-Methods " , experimentei adicionar definições de configuração ao meu código Angular, mas depois de algumas horas tentando convencer o Chrome a chamar um serviço da Web JSON entre domínios, desisti miseravelmente.

No final, eu adicionei uma página web mudo manipulador ASP.Net, tem que ligar para o meu serviço JSON web, e retornar os resultados. Começou a funcionar em 2 minutos.

Aqui está o código que eu usei:

public class LoadJSONData : IHttpHandler
{
    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "text/plain";

        string URL = "......";

        using (var client = new HttpClient())
        {
            // New code:
            client.BaseAddress = new Uri(URL);
            client.DefaultRequestHeaders.Accept.Clear();
            client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
            client.DefaultRequestHeaders.Add("Authorization", "Basic AUTHORIZATION_STRING");

            HttpResponseMessage response = client.GetAsync(URL).Result;
            if (response.IsSuccessStatusCode)
            {
                var content = response.Content.ReadAsStringAsync().Result;
                context.Response.Write("Success: " + content);
            }
            else
            {
                context.Response.Write(response.StatusCode + " : Message - " + response.ReasonPhrase);
            }
        }
    }

    public bool IsReusable
    {
        get
        {
            return false;
        }
    }
}

E no meu controlador Angular ...

$http.get("/Handlers/LoadJSONData.ashx")
   .success(function (data) {
      ....
   });

Tenho certeza de que existe uma maneira mais simples / mais genérica de fazer isso, mas a vida é muito curta ...

Isso funcionou para mim, e eu posso continuar fazendo o trabalho normal agora !!

Para um projeto IIS MVC 5 / Angular CLI (Sim, eu estou ciente de que seu problema está com o Angular JS) com API, fiz o seguinte:

web.config no <system.webServer>nó

    <staticContent>
      <remove fileExtension=".woff2" />
      <mimeMap fileExtension=".woff2" mimeType="font/woff2" />
    </staticContent>
    <httpProtocol>
      <customHeaders>
        <clear />
        <add name="Access-Control-Allow-Origin" value="*" />
        <add name="Access-Control-Allow-Headers" value="Content-Type, atv2" />
        <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS"/>
      </customHeaders>
    </httpProtocol>

global.asax.cs

protected void Application_BeginRequest() {
  if (Request.Headers.AllKeys.Contains("Origin", StringComparer.OrdinalIgnoreCase) && Request.HttpMethod == "OPTIONS") {
    Response.Flush();
    Response.End();
  }
}

Isso deve corrigir seus problemas para o MVC e o WebAPI sem ter que fazer tudo o que for possível. Em seguida, criei um HttpInterceptor no projeto CLI Angular que foi adicionado automaticamente às informações relevantes do cabeçalho. Espero que isso ajude alguém em uma situação semelhante.

Um pouco tarde para a festa,

Se você estiver usando Angular 7 (ou 5/6/7) e PHP como a API e ainda estiver recebendo esse erro, tente adicionar as seguintes opções de cabeçalho ao ponto final (PHP API).

 header("Access-Control-Allow-Origin: *");
 header("Access-Control-Allow-Methods: PUT, GET, POST, PUT, OPTIONS, DELETE, PATCH");
 header("Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization");

Nota : O que requer apenas é Access-Control-Allow-Methods. Mas, eu estou colando aqui outros dois Access-Control-Allow-Origine Access-Control-Allow-Headers, simplesmente porque você precisará que todos eles sejam configurados corretamente para que o Angular App fale corretamente com sua API.

Espero que isso ajude alguém.

Felicidades.