J'essaie de créer un WebAPI DNN Service Framework mais j'ai du mal à le consommer avec CORS. J'ai tous les en-têtes appropriés (je pense) mais cela ne semble toujours pas fonctionner.
Erreur:
XMLHttpRequest cannot load http://www.dnndev.me/mysite/builder/API/echo?message=Hello+World&_=1412707749275. Request header field Key is not allowed by Access-Control-Allow-Headers.
En-têtes de demande:
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
En-têtes de réponse:
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
Généralement, cette erreur serait due au fait de ne pas avoir l'en-tête approprié dans "Access-Control-All-Headers". Cependant, j'envoie la bonne réponse pour permettre à ajax de poursuivre sa demande. Il refuse tout simplement.
Voici mon appel ajax à la méthode:
$.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); }
});
Probablement évident, mais cela ne se produit que sur les demandes interdomaines et uniquement lorsque j'inclus l'en-tête personnalisé (donc procurant ajax pour faire une OPTIONS).
Votre serveur répond avec l'en-tête personnalisé suivant à la demande de contrôle en amont:
Access-Control-All-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
alors que si vous (ou la personne qui a écrit ce serveur) avez lu attentivement CORS, il aurait dû répondre par:
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
Maintenant, le client client peut continuer et utiliser l'en-tête personnalisé Key
.
Ceci étant dit, Bearer
est assez spécifique à OAuth 2 qui est envoyé dans l'en-tête Authorization
. L'utilisation de Key
semble être une violation terrible des RFC et des trucs et une réinvention de roue un peu.
Ajoutez ceci à vos en-têtes de réponse de serveur:
en-tête ("Access-Control-Allow-Headers: Origin, Content-Type, X-Auth-Token, Authorization");
Veuillez noter la faute de frappe dans la question de Nyx et la réponse de Darin ('ow' manquant). Alors c'est
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Key
et il résout le message d'erreur "Champ d'en-tête de demande n champ d'en-tête n'est pas autorisé par Access-Control-Allow-Headers en mode de contrôle en amont", s'il est envoyé en réponse à la demande OPTION du navigateur.