已登录Admin时AngularJS PATCH请求出现CSRF Failed 403，未登录正常

看起来你遇到的问题核心是登录Django Admin后，AngularJS的PATCH请求没有正确携带符合Django要求的CSRF Token，导致后端的CSRF中间件拦截了请求。未登录时请求正常，大概率是因为Django对未认证用户的CSRF验证规则更宽松（或者你的后端在未登录时跳过了验证），但登录后启用了严格的CSRF校验。

下面是具体的解决方案：

方案1：配置AngularJS适配Django的CSRF规则 #

Django默认的CSRF Cookie名称是csrftoken，并且期望请求头携带X-CSRFToken；而AngularJS默认会读取XSRF-TOKEN Cookie，发送X-XSRF-TOKEN请求头。两者不匹配是问题的关键。

你可以修改AngularJS的$httpProvider配置，让它适配Django的规则：

angular.module('yourAppName', [])
.config(['$httpProvider', function($httpProvider) {
    // 告诉AngularJS读取名为csrftoken的Cookie
    $httpProvider.defaults.xsrfCookieName = 'csrftoken';
    // 告诉AngularJS在请求头中发送X-CSRFToken
    $httpProvider.defaults.xsrfHeaderName = 'X-CSRFToken';
}]);

这个配置会让AngularJS自动从Cookie中获取最新的csrftoken，并在所有不安全的请求（包括PATCH）中带上对应的请求头，完美匹配Django的CSRF验证逻辑。

方案2：修改Django配置适配AngularJS默认规则 #

如果你不想改动前端代码，可以在Django的settings.py中调整CSRF相关配置：

# settings.py
# 将CSRF Cookie名称改为AngularJS默认的XSRF-TOKEN
CSRF_COOKIE_NAME = 'XSRF-TOKEN'
# 设置Django期望的请求头为AngularJS默认发送的X-XSRF-TOKEN
CSRF_HEADER_NAME = 'HTTP_X_XSRF_TOKEN'

这样Django就会和AngularJS的默认行为对齐，无需前端修改。

验证步骤 #

配置完成后，你可以用浏览器开发者工具验证是否生效：

• 登录Admin面板后，发起PATCH请求
• 打开Network标签，找到该请求，查看Request Headers
• 确认存在X-CSRFToken（方案1）或X-XSRF-TOKEN（方案2）请求头，且其值和Cookie中的对应token一致

如果请求头正确携带了token，后端的CSRF验证就会通过了。

内容的提问来源于stack exchange，提问作者nohtyp