XSRF les en-têtes de ne pas être mis en AngularJS

Je suis l'élaboration d'un DJANGO + AngularJS demande, lorsque la partie angulaire n'est pas servi par django.

- Je régler l'angle de $httpProvider comme suit:

myApp = angular.module('myApp', [])

myApp.config(['$httpProvider',
  function(provider){
    provider.defaults.xsrfCookieName = 'csrftoken';
    provider.defaults.xsrfHeaderName = 'X-CSRFToken';
}

Alors, avant de faire un POST, je fais un GET qui définit le cookie. Je peux confirmer par le biais de google Chrome qui le cookie est défini:

set-cookie:csrftoken=hg88ZZFEdLPnwDdN1eiNquA8YzTySdQO; expires=Tue, 19-Aug-2014 12:26:35 GMT; Max-Age=31449600; Path=/

(il est visible sur les ressources/cookies/localhost dans les outils de développement Chrome)

Cependant, quand je fais un POST, pas de X-CSRFToken en-tête est défini

c'est de la POST enregistrées par google Chrome:

POST /data/activities/search HTTP/1.1
Host: localhost:14080
Connection: keep-alive
Content-Length: 2
Accept: application/json, text/plain, */*
Origin: http://localhost:14080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.95 Safari/537.36
Content-Type: application/json;charset=UTF-8
Referer: http://localhost:14080/public/html/main.html?codekitCB=398694184.799418
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: csrftoken=hg88ZZFEdLPnwDdN1eiNquA8YzTySdQO

Pourquoi pas d'en-tête en cours de jeu? Que dois-je faire pour activer cette fonctionnalité?

(note de côté: si je manuellement passer la tête dans l' $http() l'appel, la requête POST fonctionne très bien.. donc le problème est vraiment l'en-tête n'étant pas définie par AngularJS)

J'ai été en utilisant 1.0.8, mais j'ai découvert il n'est disponible que depuis la version 1.2.0

OriginalL'auteur luca | 2013-08-20

  1. 8

    réponse très simple: il est uniquement disponible à partir de la version 1.2.0, qui est pour le moment une version release candidate.

    Et cette réponse, c'est très mal, car je l'utilise dans 1.1.5.
    Et qui dit 1.1.5, dit-1.0.x 🙂
    non, c'est correct, la nouvelle façon automatique (le seul objet de cette question) est seulement à partir angulaire 1.2, vous le faites manuellement (ce qui peut toujours être utile)
    Il est intéressant aussi de noter que si vous utilisez django vues de réponse à ce contexte, vous aurez toujours pas de csrf_token si il n'y a pas de formes dans le modèle (il y a souvent l'habitude d'être). C'est pourquoi vous pouvez avoir besoin d'utiliser la ensure_csrf_cookie décorateur, de sorte que l'angle d'appels de l'api aura le jeton dont ils ont besoin.

    OriginalL'auteur luca

  2. 5

    La version 1.2.0 mise à jour n'était pas suffisant pour moi lors de l'utilisation de Safari ou Firefox (Chrome a été fonctionne correctement tout le temps). Le problème avec Safari et Firefox était que le Django backend de ne pas envoyer les csrf-cookie dans la réponse HTTP.

    Ce que j'avais à faire était d'ajouter le @ensure_csrf_cookie décorateur de mon point de vue, la fonction qui construit la page pour Angularjs.

    @ensure_csrf_token
def my_view(request):
    ...

    et dans le fichier javascript:

    myApp.config(function($httpProvider) {
    $httpProvider.defaults.xsrfCookieName = 'csrftoken';
    $httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';
}

    Au moins pour l'instant, je n'ai aucune idée de pourquoi Chrome fonctionne sans elle, mais les autres navigateurs ne le font pas.

    comment importer @ensure_csrf_token ?
    Uuh, je suppose que j'ai une erreur de frappe dans l'exemple. C'est @ensure_csrf_cookie qui peut être trouvé dans django.les vues.les décorateurs.csrf.ensure_csrf_cookie

    OriginalL'auteur Janne

  3. 2

    J'ai eu un problème similaire et c'était embarrassant de ma faute.

    De mon erreur:

    $.post('/url', data)

    Assurez-vous que vous utilisez le $http objet!

    $http.post('/url', data)

    Il était très facile de faire cette erreur, puisque les deux semblent fonctionner tout aussi bien les uns que les autres, à l'exception de l'ancien n'a pas l'air au $http.defaults.headers.common['X-CSRFToken'], etc.

    Heh. Nice post. Je n'ai pas fait, mais ça me titille. Idéal pour partager votre visage rouge moments!

    OriginalL'auteur Gerald Kaszuba

  4. 1
    app.config(["$httpProvider", function($httpProvider) {
    var csrfToken = getCookie('csrftoken');
    $httpProvider.defaults.headers.common['X-CSRFToken'] = csrfToken; 
}])

    getCookie() de prendre de https://docs.djangoproject.com/en/dev/ref/contrib/csrf/

    Ou de paramétrer chaque méthode séparément

     $httpProvider.defaults.headers.post['X-CS....
 $httpProvider.defaults.headers.get['X-CS....

    OriginalL'auteur Serge K.

  5. 1

    Angulaire change très souvent et certaines réponses ne fonctionnent pas avec les dernières versions. De toute manière, depuis Angulaire s'attend à un XSRF-TOKEN le nom du cookie, et envoie un X-XSRF-TOKEN en-tête, on peut aussi simplement dire Django à l'utilisation de ces par défaut:

    CSRF_COOKIE_NAME = 'XSRF-TOKEN'
CSRF_HEADER_NAME = 'HTTP_X_XSRF_TOKEN'

    Le premier paramètre (voir docs) est le nom du cookie pour le jeton csrf, tandis que la seconde (voir docs, introduit en 1.9) est le nom d'en-tête.

    Dernier, seulement pour la référence, ne pas oublier de mettre:

    CSRF_COOKIE_HTTPONLY = False

    OriginalL'auteur Wtower