Ajout d'un en-tête personnalisé à une requête HTTP à l'aide d'angular.js

Question

Je suis novice en angular.js et j'essaie d'ajouter des en-têtes à une requête :

   var config = {headers: {
            'Authorization': 'Basic d2VudHdvcnRobWFuOkNoYW5nZV9tZQ==',
            'Accept': 'application/json;odata=verbose'
        }
    };

   $http.get('https://www.example.com/ApplicationData.svc/Malls(1)/Retailers', config).success(successCallback).error(errorCallback);

J'ai regardé toute la documentation, et il me semble que cela devrait être correct.

Lorsque j'utilise un fichier local pour l'URL dans le champ $http.get Je vois la requête HTTP suivante sur l'onglet réseau dans Chrome :

GET /app/data/offers.json HTTP/1.1
Host: www.example.com
Connection: keep-alive
Cache-Control: max-age=0
If-None-Match: "0f0abc9026855b5938797878a03e6889"
Authorization: Basic Y2hhZHN0b25lbWFuOkNoYW5nZV9tZQ==
Accept: application/json;odata=verbose
X-Requested-With: XMLHttpRequest
If-Modified-Since: Sun, 24 Mar 2013 15:58:55 GMT
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
X-Testing: Testing
Referer: http://www.example.com/app/index.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Comme vous pouvez le voir, les deux en-têtes ont été ajoutés correctement. Mais lorsque je change l'URL pour celle qui figure dans l'en-tête $http.get ci-dessus (sauf que j'utilise l'adresse réelle, pas exemple.com), puis j'obtiens :

OPTIONS /ApplicationData.svc/Malls(1) HTTP/1.1
Host: www.datahost.net
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://mpon.site44.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22
Access-Control-Request-Headers: accept, origin, x-requested-with, authorization, x-testing
Accept: */*
Referer: http://mpon.site44.com/app/index.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

La seule différence de code entre ces deux-là est que pour la première, l'URL est un fichier local, et pour la seconde, l'URL est un serveur distant. Si vous regardez le deuxième en-tête de demande, il n'y a pas d'en-tête d'authentification, et l'en-tête Accept semble utiliser une valeur par défaut au lieu de celle spécifiée. En outre, la première ligne indique maintenant OPTIONS au lieu de GET (bien que Access-Control-Request-Method es GET ).

Une idée de ce qui ne va pas avec le code ci-dessus, ou comment obtenir les en-têtes supplémentaires inclus en utilisant quand on n'utilise pas un fichier local comme source de données ?

Answer 1

Et quelle est la réponse du serveur ? Il devrait répondre un 204 et ensuite envoyer réellement le GET que vous demandez.

Dans les OPTIONS, le client vérifie si le serveur autorise les demandes CORS. S'il vous donne autre chose qu'un 204, vous devez configurer votre serveur pour qu'il envoie les bons en-têtes Allow-Origin.

La façon dont vous ajoutez les en-têtes est la bonne façon de procéder.

Answer 2

Chrome effectue un contrôle préalable de la demande pour rechercher les en-têtes CORS. Si la requête est acceptable, il envoie alors la requête réelle. Si vous effectuez cette opération sur plusieurs domaines, vous devrez simplement faire face à ce problème ou trouver un moyen de rendre la requête non inter-domaine. C'est un choix délibéré.

Contrairement aux requêtes simples (discutées ci-dessus), les requêtes "preflighted" commencent par d'abord envoyer une requête HTTP par la méthode OPTIONS à la ressource sur l'autre l'autre domaine, afin de déterminer si la demande réelle est sûre. à envoyer. Les requêtes intersites sont prévisualisées de la sorte car elles peuvent avoir des implications sur les données de l'utilisateur. En particulier, une demande est pré-vérifiée si :

Il utilise des méthodes autres que GET, HEAD ou POST. De même, si POST est utilisé pour envoyer des données de demande avec un Content-Type autre que application/x-www-form-urlencoded, multipart/form-data ou text/plain, par exemple, si la requête POST envoie une charge utile XML au serveur en utilisant le paramètre application/xml ou text/xml, alors la demande est préfiltrée. Il définit des en-têtes personnalisés dans la demande (par exemple, la demande utilise un en-tête tel que X-PINGOTHER)

Réf : AJAX dans Chrome envoie des OPTIONS au lieu de GET/POST/PUT/DELETE ?

Answer 3

Vous ajoutez simplement un en-tête que le serveur n'autorise pas.

par exemple, votre serveur est configuré CORS pour n'autoriser que ces en-têtes (accept, cache-control, pragma, content-type, origin).

et dans votre requête http vous ajoutez comme ceci

 headers: {
        'Authorization': 'Basic d2VudHdvcnRobWFuOkNoYW5nZV9tZQ==',
        'Accept': 'application/json',
        'x-testing': 'testingValue'
    }

alors le serveur rejettera cette demande puisque (Authorization et x-testing) ne sont pas autorisés.

Il s'agit d'une configuration côté serveur.

Et il n'y a rien à faire avec les options HTTP, c'est juste un contrôle préalable au serveur qui est d'un domaine différent pour vérifier si le serveur permettra l'appel réel ou non.

Answer 4

Pour moi, l'extrait explicatif suivant a fonctionné. Vous ne devriez peut-être pas utiliser ' pour le nom de l'en-tête ?

{
   headers: { 
      Authorization: "Basic " + getAuthDigest(), 
      Accept: "text/plain" 
   }
}

J'utilise $http.ajax() mais je ne m'attends pas à ce que cela change la donne.