Django项目系统学习（四）

Day8

视图函数

目前业务逻辑，也就是视图函数放在了user下面的views.py中，我们是定义了一个函数user_login。
按照视频主的意思，更多用的是基于类的逻辑处理，例如此处的登陆验证。
于是继承了View，定义了类LoginView，在类里面定义了两个函数，get()与post()，省去了条件判断request的方法了。

表单文件forms.py

出现这个文件的目的是减轻后台逻辑处理的压力，例如前端填写表单数据时，某些字段要求必填，某些字段由长度限制。此时，加一个类似“中间件”，对前端传来的表单数据先进行一次筛选，有利于后台纯粹的处理业务逻辑。
另外，前端JS也是会判断字段的，但是无论前端判断不判断，作为后台，必须进行判断，以免攻击者绕过前端验证，长驱直入后台。

Day 9

总结

最近学习项目的进度越来越慢了，几个小时就弄了一点点东西，效率实在太低，这样不行。

表单验证

昨天在后台views.py中写了一个Login_form(forms.Form)，用来对前端传来的数据先进行字段验证，验证结束后，Login_form的实例是会报错的，例如说

该字段最小长度为5，目前为3

现在解决的问题就是将这个错误信息从后台传到前端中。
现在遇到了一个很有趣的情况，我到目前，一直认为前端语言中class的值是自己任意取的，而且取得值只是个标记，没有太多影响。但是再看小程序代码中遇到了，很长的值，不知所云。现在发现值还是有用的。例如下面的 errorput,会将前端输入框变红。

代码errorput

前端变红

cookie与session

http协议是无状态协议，也就是指浏览器对服务器的两次请求之间没有关联。

无状态请求

但是类似淘宝的网站存在“记住”用户的需求，从而产生了cookie，要注意，cookie是浏览器的本地存储机制。

有状态请求

但是cookie因为存储在本地，所有容易被人窃取，不安全。因此延申出了session，session是存储在服务器的。他是根据用户名密码等信息生成一条加密的随机字符串，保存在服务器上。服务器将session发给用户，用户将session保存在cookie中，用户在做下次请求时，将cookie包含之前的session带回给服务器。服务器通过sessionid在数据库中查询就知道是哪个用户了。
从而完成自动登录。