上一章是业务如何前后端分离，配置多级路由，如何去写一个view函数，因为采用了前后端分离，数据在http下，最好的表达方式就是json了，想办法把用户里的请求数据提取到，用json返回回去。
前端的很多库都可以 用ajsx，将json数据通过请求发过来，也可以将自己处理好的数据通过json发回去，也就是request是json，response也是json。
格式是前端的事情，我们玩的就是数据
用户名重复验证的还没解决，还有一个打开csrf，就要开始出问题了
在post的时候会有csrf的问题，处理方式有两种：
1.系统是在内部的，直接加注释把插件禁用
2.如果是互联网的，就不要去掉，因为可以防一些欺骗手段
取消注释，提交就报错
对于django来讲，为了解决安全问题。，提供了很多功能，其中一个就是在默认情况下，使用了一个中间件，会拒绝post，只要post来的不带有它的信息，就拒绝，就需要做csrf校验
csrf（cross-site request forgery）跨站请求伪造，get只是看看，post可能是修改，也可能插入新数据，所以非常危险，要对这个进行一些阻止。能增大攻击难度的。
第一次响应用户端请求的时候，就会生成一个token，这个token会放在cookie里面，浏览器每一次post的时候，必须把token带上，不带上就检验不合格，直接拒绝服务
加上以后就解决一部分问题，不推荐直接禁用，这里是用的中间件技术，相当于在请求的过程中就要检验，如果请求不带，就会拒绝
第二种办法是在表单当中，在模版的form表单中增加(%csrf_token %)，里面记录了当前的一个值，这个值只是其中一个控件，还会在浏览器的cookie中再加一个csrftoken字段。
加了两个东西，客户端提交会把这两个东西在服务端会用中间件进行验证
官方还提供了，如果不想关，又不想通过表单的方式，很多情况下会采用json的方式，如果使用ajax进行post，就要在请求头部增加一个x-CSRFTOKEN，有这样一个头，把从cookie里获得的csrftoken值，进行检验。
一般提交都是要网页的，只要在网页里加上csrftoken就可以得到这个值了
现在发回来的header
401是登录验证，403是没有权限直接拒绝
也就是现在插件启用了，不准post了。
中间件的意思是当你的请求到达server之间，中间还没有到达最后的view函数，中间挨着个的过，路过csrf的中间件的时候，csrf说拒绝，就直接return了，连view函数看都没看到，在到view之前要经过很多中间件（拦截器interceptor），总之一个是来的路上把request全部拦一遍，一个从view response之前，全部检查一遍
怎么解决csrftoken，现在是异步 的方式，类似ajax方式，让我们需要建立一个header，X-CSRFTOKEN
将这个cookie写入到了类似ajax这种异步提交方式，在其中写一个header，在header里增加了一个X-CSRFTOKEN，将这个值带上
这个token已经发过了，到现在为止没过期，还可以用。所以现在用的方式很简单，用get方法获得一个模版页面，在模版页面带入这个东西 ，可以去里面拿cookie，等有了cookie，将这个cookie值填入到里面凑一个header，然后再send就让你过了
拿到页面之后想办法要一次token即可，token拿到以后塞入到上面然后传送即可
不发送token就立马403了
现在先注释掉，便于下面测试
第一个业务就需要先做下邮箱检查，在用户输入了地址，就要对邮箱进行检查（客户端也会不用浏览器，直接用postman这样的工具发送检查）
save方法会自动保存数据提交，默认是save，delete事务会自动提交，如果出现错误，会自动取消提交，rollback。同时会将异常抛出
有了异常应该返回一些，比如告诉邮箱冲突。
save方法保存异常，可以向外抛出异常，捕获，return httpresponsebadrequest。
django的异常是继承自httpresponse的，就需要return一个实体的对象回。
前端通过返回的状态码来判断成功与否
如果用户名冲突，可以在httpresponsebadrequest里（直接写用户名冲突），这样前端就会拿到这个jsonresponse，不一定非要用httpresponsebadrequest，还可以用json，
json需要改下状态码，里面可以写一堆字符串原因，你说错误什么，前端就显示错误什么，错误与否就靠状态码来判断，200系列正确，400错误
是不是可以加一下运行时候的sql语句，就知道我们写的对不对了
看一下官方文档
点击日志
logger还有级别
这一块就是导入logging模块
这个是添加到settings里的东西，添加了，基本上就可以使用 了
复制这部分贴到settings里去
默认定义 一个handle，是控制台的console，logging模块里创建streamhandler，streamhandler默认往控制台走，
这里降低点，用debug，保存
django创建了好几个logger，直接使用
这个logger放在loggers里了，这个logger里最后用控制台console，然后级别是debug
保存就可以看到消息了，这就是为什么服务启动的时候，数据库配置错误为什么过不去，也就是这里已经连接过数据库了
要注意一点，debug必须等于true，debug如果等于false，logger这块就是把界别给的最低了，也打印不出来
如果是debug=false，就必须加上这个网站允许的主机，谁能访问必须有
现在日志就加好了
email验证就需要想想办法
这里能生成where email=xxxx你的值
打印保存一下
send一把，reason来了，说明执行了
看一下执行了什么。类型是一个查询集，就可以操作所有的结果
注释掉query.query）因为到save冲突了，是唯一键冲突
再执行一遍
波浪线打印完就到了。27，28行
（记得sqlalchemy是足够懒）作为这个orm也是懒的，不调用消费者方法，根本不查
这样写是相当于用一下
再执行一遍
就进行查询了，做if的时候查询了下，查到后就得到了想要的数据
这里是sqlalchemy一样，有类似的消费者方法。
这里想做的操作是，如果email存在就return error，如果first拿到，就应该是一个真正对象，拿不到first就是none，if none就进不来，如果进来了就说明email拿到了，就不能insert了，就需要返回httpresponsebadrequest（‘你的字符串’）
这里就返回用户名已经存在了
这个写法是有风险的，query是个对象，如果不提供length，不提供布尔的话是永久以为是真
所以最好加个first
用这种日志的方式，可以看到什么增删改查看的清清楚楚
为了防止sql注入，使用了参数化查询，参数化查询必须要用
把没有拼凑的查询语句编译了,编译了提高效率，省得下一次还需要编译，尤其语句复杂的，只要换参数就可以查询了，但是架不住使用like。
面试可能会问sql注入攻击，参数化查询是什么样子的