csrf cookie ajax,Django使用csrf时cookie没有csrf_token的问题

本文详细探讨了Django中CSRF_TOKEN的设置与使用流程,包括 CsrfViewMiddleware 的工作原理,以及如何通过HTML模板、手动设置或AJAX提交确保CSRFTOKEN的有效性。重点解释了{% csrf_token %}

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天被这个问题困扰了一上午,理清以后发觉正常情况下是不会遇到这个问题的。

遇到这个问题的前提是什么呢?

习惯ajax方式提交POST请求

习惯从cookie里找csrftoken

这次是在一个新建的project里遇到的这个问题,旧project的base foundation都比较完善,所以才没有特别注意csrftoken的来源问题。

一般我们认为cookie里的csrftoken是由csrftoken middleware所设置的,事实确实如此,但也不完全是。贴一段CsrfViewMiddleware的代码:

def process_response(self, request, response):

if getattr(response, 'csrf_processing_done', False):

return response

# If CSRF_COOKIE is unset, then CsrfViewMiddleware.process_view was

# never called, probably because a request middleware returned a response

# (for example, contrib.auth redirecting to a login page).

if request.META.get("CSRF_COOKIE") is None:

return response

# 重点在这里

if not request.META.get("CSRF_COOKIE_USED", False):

return response

# Set the CSRF cookie even if it's already set, so we renew

# the expiry timer.

response.set_cookie(settings.CSRF_COOKIE_NAME,

request.META["CSRF_COOKIE"],

max_age=settings.CSRF_COOKIE_AGE,

domain=settings.CSRF_COOKIE_DOMAIN,

path=settings.CSRF_COOKIE_PATH,

secure=settings.CSRF_COOKIE_SECURE,

httponly=settings.CSRF_COOKIE_HTTPONLY

)

# Content varies with the CSRF cookie, so set the Vary header.

patch_vary_headers(response, ('Cookie',))

response.csrf_processing_done = True

return response

这段代码的重点在于对CSRF_COOKIE_USED的检查,如果没有设置,middleware会直接返回response而不在cookie里设置csrftoken。

而CSRF_COOKIE_USED是在哪设置的呢?有几种途径:

手动设置。在你的view里添加request.META["CSRF_COOKIE_USED"] = True

手动调用csrf middleware的get_token(request)或rotate_token(request)方法

在你的html模板里添加 {% csrf_token %}

我今天的问题就在于第三种途径。旧project里是有添加的,而新project里没有,所以导致了我的问题。

官方文档建议在每一个form里都添加这样的标签,这样能够在提交表单时自动将csrftoken添加进请求里。

对于ajax post文档也指出从cookie拿会比较方便。

那这个标签具体做了什么呢?

使用这个标签会让django模板引擎在这里插入一个隐藏的input用来存放csrftoken。在django.template.defaulttags里我们可以找到一个叫CsrfTokenNode的类,它的render方法检查了context里的csrf_token。

def render(self, context):

csrf_token = context.get('csrf_token', None)

if csrf_token:

if csrf_token == 'NOTPROVIDED':

return format_html("")

else:

return format_html("", csrf_token)

else:

...

context中的csrf_token是一个django.template.context_processors.csrf的实例,他本身就等同于自己的_get_val(),只不过是在每次用到自己的时候才调用该方法获得返回值。(这部分也是值得一写的内容)

所以可以看到在上面的render方法中的第二行,有一次对csrf_token的判断,正是在这里调用了_get_val,在_get_val中调用了get_token,get_token会从request里取CSRF_COOKIE,CSRF_COOKIE又是由middleware在process_view中提供的,所以最终会让CsrfViewMiddleware在process_response里把csrftoken添加进cookie里,也就可以在前端拿到cookie了。

总结一下,这之间发生的事情就是:

html文件添加{% csrf_token %}标签

CsrfViewMiddleware在process_view时向request添加CSRF_COOKIE

渲染模板检测到该标签,在渲染时添加CsrfTokenNode类

CsrfTokenNode的渲染方法检查csrf_token

对csrf_token进行判断时调用get_token

get_token检查request中的CSRF_COOKIE,并设置CSRF_COOKIE_USED为True

CsrfViewMiddleware在process_response设置cookie中的csrftoken

这样前端就能看到cookie了。

以上就是对这个问题的解决办法的记录。