2014-10-07 13 views
14

Tentativo di creare una WebAPI di servizio DNN, ma ho problemi a consumarlo con CORS. Ho tutte le intestazioni appropriate (credo) ma sembra che non funzioni.Campo di intestazione richiesta Ajax La chiave non è consentita da Access-Control-Allow-Headers

errore:

intestazioni di richiesta:

Remote Address: 127.0.0.1:80 
URL: http://www.dnndev.me/mysite/builder/API/echo?message=Hello 
Request Method: OPTIONS 
Status Code: 200 OK 
Accept: */* 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-US,en;q=0.8 
Access-Control-Request-Headers: accept, key 
Access-Control-Request-Method: GET 
Connection: keep-alive 
Host: www.dnndev.me 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 

risposta intestazioni:

Access-Control-All-Headers: Origin, X-Requested-With, Content-Type, Accept, Key 
Access-Control-Allow-Methods: * 
Access-Control-Allow-Origin: * 
Cache-Control: no-cache 
Content-Length: 13 
Content-Type: application/json; charset=utf-8 
Date: Tue, 07 Oct 2014 18:49:10 GMT 
Expires: -1 
Pragma: no-cache 
Server: Microsoft-IIS/7.5 

In genere, questo errore sarebbe stato causato da non avere l'intestazione appropriata 'Access- Control-All-intestazioni. Tuttavia, sto inviando la risposta corretta per consentire a ajax di continuare con la sua richiesta. Semplicemente si rifiuta di farlo.

Qui è la mia chiamata AJAX al metodo:

$.ajax({ 
    type: 'GET', 
    url: 'http://www.dnndev.me/mysite/builder/API/echo', 
    dataType: 'json', 
    data: { message: 'Hello' }, 
    crossDomain: true, 
    headers: { 'Key': 'Bearer 7680ff6e-1362-4236-a9cd-c6bc8b6f13ea' }, 
    success: function (result) { console.log(result); } 
}); 

Probabilmente ovvio, ma questo accade solo sulle richieste dominio trasversali e solo quando includo l'intestazione personalizzata (quindi procing ajax per fare un opzioni).

risposta

21

Il server risponde con la seguente intestazione personalizzata alla richiesta di verifica preliminare:

Access-Control-All-Headers: Origin, X-Requested-With, Content-Type, Accept, Key 

mentre se voi (o la persona che ha scritto questo server) di leggere attentamente i CORS avrebbe dovuto risposto con:

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Key 

Ora il client client può andare avanti e utilizzare l'intestazione personalizzata Key.

Detto questo, Bearer è piuttosto specifico per OAuth 2 che viene inviato attraverso l'intestazione Authorization. L'utilizzo di Key sembra una terribile violazione di RFC e roba e una reinvenzione delle ruote.

+0

Grazie! Non l'avrei mai notato. Le piccole cose ... – NorianNyx

+0

L'uso di Bearer è una vecchia idea in cui stavo usando OAuth 2. Non ho ancora cambiato l'intestazione. – NorianNyx

2

Si prega di notare l'errore di battitura nella domanda di Nyx e la risposta di Darin ('ow' mancante). Quindi è

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Key 

e si risolve il messaggio di errore 'richiesta campo di intestazione qualche campo-header- non è consentita da Access-Control-Allow-intestazioni in modalità preflight', se inviati in risposta al browser del Richiesta di OPZIONE

1

Aggiungere questo ai vostri header di risposta del server:

intestazione ('Access-Control-Allow-intestazioni: le sue origini, Content-Type, X-Auth-token, l'autorizzazione');

Problemi correlati