web-dev-qa-db-fra.com

CORS - Comment "contrôler en amont" une requête http?

J'essaie de faire une demande HTTP interdomaine au service WCF (que je possède). J'ai lu plusieurs techniques pour travailler avec les limitations de script entre domaines. Étant donné que mon service doit prendre en charge les requêtes GET et POST, je ne peux pas implémenter de balise de script dynamique dont src est l'URL d'une requête GET. Étant donné que je suis libre d’effectuer des modifications sur le serveur, j’ai commencé à essayer d’implémenter une solution de contournement qui implique de configurer les réponses du serveur de manière à inclure l’en-tête "Access-Control-Allow-Origin" et les demandes de contrôle en amont avec et la demande OPTIONS. J'ai eu l'idée de ce post: Faire fonctionner la SCRO

Du côté du serveur, ma méthode Web ajoute 'Access-Control-Allow-Origin: *' à la réponse HTTP. Je peux voir que les réponses incluent cet en-tête maintenant. Ma question est la suivante: comment "pré-contrôler" une demande (OPTIONS)? J'utilise jQuery.getJSON pour effectuer la demande GET mais le navigateur annule immédiatement la demande avec l'infâme:

Origin http: // localhost n'est pas autorisé par Access-Control-Allow-Origin

Quelqu'un est-il familier avec cette technique CORS? Quelles modifications doivent être apportées chez le client pour contrôler en amont ma demande?

Merci!

javascriptwcfjquerycors
86
Nick

Pendant la demande de contrôle en amont, vous devez voir les deux en-têtes suivants: Méthode de demande de contrôle d'accès et En-têtes de demande de contrôle d'accès. Ces en-têtes de demande demandent au serveur les autorisations nécessaires pour effectuer la demande. Votre réponse de contrôle en amont doit reconnaître ces en-têtes pour que la demande réelle fonctionne.

Par exemple, supposons que le navigateur envoie une requête avec les en-têtes suivants:

Origin: http://yourdomain.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-Custom-Header

Votre serveur devrait alors répondre avec les en-têtes suivants:

Access-Control-Allow-Origin: http://yourdomain.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: X-Custom-Header

Portez une attention particulière à l'en-tête de réponse Access-Control-Allow-Headers. La valeur de cet en-tête doit être identique à celle de l'en-tête de la demande Access-Control-Request-Headers et ne peut pas être '*'. 

Une fois que vous avez envoyé cette réponse à la demande de contrôle en amont, le navigateur effectue la demande. Vous pouvez en apprendre plus sur CORS ici: http://www.html5rocks.com/en/tutorials/cors/

142
monsur

Bien que ce fil remonte à 2014, le problème peut toujours être d'actualité pour beaucoup d'entre nous. Voici comment je l'ai traité dans un contexte jQuery 1.12/PHP 5.6:

  • jQuery a envoyé sa demande XHR en utilisant uniquement des en-têtes limités; seul 'Origine' a été envoyé. 
  • Aucune demande de contrôle en amont n'était nécessaire.
  • Le serveur devait seulement détecter une telle requête et ajouter le code "Access-Control-Allow-Origin:". $ _SERVER ['HTTP_Origin'] en-tête, après avoir détecté qu'il s'agissait d'un XHR croisé.

Exemple de code PHP:

if (!empty($_SERVER['HTTP_Origin'])) {
    // Uh oh, this XHR comes from outer space...
    // Use this opportunity to filter out referers that shouldn't be allowed to see this request
    if (!preg_match('@\.partner\.domain\.net$@'))
        die("End of the road if you're not my business partner.");

    // otherwise oblige
    header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_Origin']);
}
else {
    // local request, no need to send a specific header for CORS
}

En particulier, n’ajoutez pas un exit; car aucun contrôle en amont n’est nécessaire.

0
Fabien Haddadi