1 .当我们普通的访问一个GET页面的时候，没有任何{%csrf_token%},渲染的时候，context['csrf_token']不会被填充，就是不会去触发get_token方法，所以你请求几次都不会有Cookies。当我们开发一个网站的时候，如果启用CSRF防御，用户登录之前需要提交表单，表单的这个页面会嵌入{%csrf_token%}，会先触发当前登录页面的GET请求，页面render的时候，根据上面第三步，会触发lazy的get_token函数，这个函数会自动生成csrf_token，如果cookies中有的话就不生成，用csrf_token清洗出后32位，再解析出秘钥，返回给表单一个新的csrfmiddlewaretoken，至此登录页面的Cookies也已经生成并返回了，而且表单动态生成了一个csrfmiddlewaretoken。
当正式登录的时候，发送POST请求，同源策略浏览器会携带对应的Cookies，而且会携带表单生成的csrfmiddlewaretoken发送给服务端，当服务器接收到的时候转发给Django，又会来到中间层1-4的步骤。这个时候第一步process_request能获取到值，给request.META["CRSF_COOKIE"]设置值，进入URLConfig路径匹配，匹配到进去视图函数之前进入process_view，如果是GET，直接渲染页面，如果是POST，判断是否禁用防御，判断是否HTTPS安全，判断csrf_token是否为空，这些判断有一个失败，就能看到熟悉的403页面。这个时候就进入最核心的CSRF防御的Token验证过程了，首先会去Cookies中拿到csrf_token，然后如果是表单，直接拿出csrfmiddlewaretoken如果是Ajax，就从header里面拿X-CSRF-Token，根据上面的Token算法，这不是比较这两个token，因为肯定不相同，我们需要反向解析清洗出真正的csrf_secret值，对比如果相同，就是正常访问，如果不同，依然是熟悉的403页面，禁止访问。通过之后渲染页面，然后继续执行precess_response,返回给客户端。
中间件的校验过程
