django前后端结合_Django前后端分离，中间件CsrfViewMiddleware源码分析

本文分析了django前后端分离项目中关于csrf的token获取和验证的源码

前后端分离项目获取token通过提前发起get请求，后端将token存储在cookie中，第二次post请求前端将token从cookie中放到请求头中，后端验证这两个值是否一致来避免csrf攻击，写的比较简单，见谅。

django 1.11.22

djangorestframework 3.9.4

djangorestframework-jwt 1.11.0

1.通过中间件的执行顺序，CsrfViewMiddleware中间件最开始执行process_view()方法，这一步作用是从cookie中获取token值，判断如果是get请求(还包括'HEAD', 'OPTIONS', 'TRACE')就通过，如果是其他请求则验证token和请求头中的token是否一致，不一致就返回403。

2.由于第一次get请求就是为了获取token的，所以cookie中获取不到token

3.通过在get请求的视图函数里执行rotate_token(request)来获取token值。

4.从rotate_token()函数中看到，新的token值暂时存储在META中，在中间件返回响应的时候通过_set_token方法存储到cookie中。

5.接下来到了CsrfViewMiddleware中间件的process_response()方法，这是中间件返回响应的最后一步，由于函数rotate_token()中设置了request.csrf_cookie_needs_reset = True，META.get("CSRF_COOKIE_USED") =True，所以会执行_set_token()方法来设置cookie。

6.在_set_token()方法中把token值存储在cookie中，get请求获取token值到这里结束了。

7.通过postman模拟post请求，把token放到请求头

8.这次cookie中携带了token，验证token的有效性。

8.由于是post请求，还要验证cookie中的token和请求头中的token。

9.如果cookie中的token和请求头中的token一致，则验证通过，执行对应的视图函数。

10.又一次来到了CsrfViewMiddleware中间件的process_response()方法，这是中间件返回响应的最后一步，由于没有执行函数rotate_token()，所以不会执行_set_token()方法来重新设置cookie，直接返回响应，请求结束。

最后，说一下另一个获取token的函数get_token()，如果执行了这个函数，会有两种情况：

1.如果cookie中携带了token值，token值会暂时存储在META中，而这个函数会判断META中已存在token，不会修改，最后在_set_token中把这个token值重新存储到cookie中，不理解django为什么要这样做？？？

2.如果cookie中没有token值，这个函数会生成新的token值暂时存储在META中，最后在_set_token中把这个token值存储到cookie中，实现和rotate_token()函数获取token一样的效果。