La publication avec HttpProvider d'AngularJS sur un point de terminaison créé avec la vue standard de Django ou le cadre Django REST renvoie une erreur 403. Allons.
$http.post('/api/entries', {'title': 'journal intime', 'body': 'Il fait beau aujourd'hui'})
Response
{detail: "CSRF Failed: CSRF token missing or incorrect."}
C'est parce que je n'ai pas réussi à contourner correctement la protection CSRF de Django, indépendamment de l'utilisation d'AngularJS.
Il semble que la valeur de l'en-tête de demande qui stocke le jeton CSRF est différente entre la valeur utilisée par AngularJS par défaut et la valeur reconnue par Django.
Si vous lisez le document suivant, Django doit envoyer la valeur de csrftoken avec le nom d'en-tête X-CSRFToken lors d'une requête Ajax.
Cross Site Request Forgery protection | Django documentation | Django
Le HTTPProvider d'AngularJS a une option pour changer le comportement de la protection CSRF, et si vous le spécifiez, vous pouvez changer le nom de l'en-tête lors de l'envoi d'un jeton CSRF et la clé du cookie à référencer.
[AngularJS: API:
Pour configurer Django, définissez comme suit.
var myApp = angular.module('myApp', []).config(function($httpProvider) {
$httpProvider.defaults.xsrfCookieName = 'csrftoken'
$httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken'
});
Désormais, AngularJS interprétera et enverra automatiquement le jeton csrf sans que vous ayez à faire quoi que ce soit. Toutes nos félicitations.
Il y a une autre dépendance à l'utilisation d'AngularJS avec Django, et il n'est pas possible de faire une expansion variable par défaut car l'expansion variable d'AngularJS est en conflit avec le moteur de template de Django.
Vous pouvez être heureux si vous changez le symbole en vous référant à ce qui suit.
Comment résoudre un conflit de portée variable entre AngularJS et jinja2 --Qiita