session 和 token
前面我们已经根据接口文档，编写代码， 对前端发来的 Customer API请求进行处理了。
并且我们也编写了 用户登录处理的代码。
不知道大家有没有发现一个问题？
前端发来的 Customer API 请求， 我们后端代码就直接处理了， 并没有验证 这个请求是不是已经登录的管理员发出的。
如果是这样，客户端可以不需要登录，直接访问 登录后的主页， 我们编写的登录处理代码又 有什么用呢？
这就 需要我们在 处理 Customer API 请求前， 判断发出该请求的用户是否登录了。
对于请求消息的合法性验证， 通常有两种方案： session 和 token
session 方案
session 就是 会话 的意思。
session 方案 的原理如下：
-
服务端在数据库中保存一张session表。 这张表记录了一次用户登录的相关信息。
具体记录什么信息， 不同的系统各有差异， 通常 会记录 该用户的 ID 、姓名 、登录名 之类的。
Django 中 该表 名字就叫 django_session, 如下所示。
大家可以发现sessionid 通常就是 一串字符串 用来标记一个session的。 而session对应的数据在这里是加密的。
通过这张表，服务端 可以根据 session号（通常叫session ID） 查到 session 的信息数据。
- 在用户登录成功后， 服务端就在数据库session表中 中创建一条记录，记录这次会话。
也就是创建一个新的 sessionid 插入到 该表中。
同时也 放入一些 该session对应的数据到 记录的数据字段中，比如登录用户 的 信息。
然后在该登录请求的HTTP响应消息中， 的头字段 Set-Cookie 里填入 sessionid 数据。
类似这样
根据http协议， 这个Set-Cookie字段的意思就是 要求前端将其中的数据存入 cookie中。 并且随后访问该服务端的时候， 在HTTP请求消息中必须带上 这些 cookie数据。
cookie 通常就是存储在客户端浏览器的一些数据。 服务端可以通过http响应消息 要求 浏览器存储 一些数据。
以后每次访问 同一个网站服务， 必须在HTTP请求中再带上 这些cookie里面的数据。
cookie数据由多个 键值对组成， 比如：
-
该用户的后续操作，触发的HTTP请求， 都会在请求头的Cookie字段带上前面说的sessionid 。
如下所示
服务端接受到该请求后，只需要到session表中查看是否有该 sessionid 对应的记录，这样就可以判断这个请求是否是前面已经登录的用户发出的。
如果不是，就可以拒绝服务，重定向http请求到登录页面让用户登录。
token机制
使用session机制验证用户请求的合法性 的主要缺点有两个
- 性能问题
因为，验证请求是根据sessionid 到数据库中查找session表的，而数据库操作是服务端常见的性能瓶颈，尤其是当用户量比较大的时候。
- 扩展性问题
当系统用户特别多的时候，后端处理请求的服务端通常由多个，部署在多个节点上。 但是多个节点都要访问session表，这样就要求数据库服务能够被多个节点访问，不方便切分数据库以提高性能。
最近比较流行的一种token机制可以比较好的解决这些问题。
token 简单来说，就是包含了 数据信息 和 校验信息的 数据包。
Session 机制是把 数据信息（比如session表）放到 服务端，服务端数据是客户无法篡改的，从而保证验证的 可靠性。
而 token机制 数据信息 直接传给 客户端，客户每次请求再携带过来给服务端。服务端无需查找数据库，直接根据token里面的数据信息进行校验。
那么问题来了：客户数据直接发送给客户端，如果 客户端篡改了数据， 比如把自己改为 vip用户怎么办？ 服务端怎么验证数据有没有被客户端篡改（术语叫完整性验证）呢？
token 机制的原理如下：
-
服务端配置一个密钥（secret key），该密钥是服务端私密保存的，不能外泄
-
在用户登录成功后， 服务端将
用户的信息数据 + 密钥一起进行一个哈希计算， 得到一个哈希值。注意：哈希算法保证了， 哈希值只能根据 同样的 源数据得到。
如果谁修改了用户信息， 除非他知道密钥，再次使用哈希算法才能得到 正确的新的 哈希值。
所以这个哈希值，就是用来校验数据是否被修改的.
然后将 用户数据信息 和 哈希值 一起 做成一个字节串 ，这个字节串就称之为 token 。
大家可以发现 token 里面 包含了用户数据信息 和 用于校验完整性的哈希值。
然后，服务端返回给客户的HTTP响应中 返回了这个token。 通常token是放在HTTP响应的头部中的。 具体哪个头部字段没有规定，开发者可以自行定义。
-
该用户的后续操作，触发的HTTP API请求， 会在请求消息里面 带上 token 。
具体在请求消息的什么地方 存放 token， 由开发者自己定义，通常也存放在http 请求 的头部中。
服务端接收到请求后，会根据 数据信息 和 密钥 使用哈希算法再次 生成 哈希值。
如果客户修改了数据信息， 因为他不知道密钥，没法得到正确的新的哈希值，那么 服务端根据 篡改后的数据+密钥 得到的新 哈希值一定和 保存在token中的老哈希值 不同。就知道数据被修改了。
如果客户没有修改数据，服务端 根据 原来的数据+密钥 得到的哈希值 和保存在token中原来的哈希值一致，就校验通过。
校验通过后，就确信了数据没有被修改，可以放心的使用token里面的数据 进行后续的业务逻辑处理了。
上述处理中，由于不需要服务端访问查找数据库，从而大大了提高了处理性能。
使用session验证客户端请求
Django 对session 的支持是 缺省就有的，下面我们来看看如何加入对API请求的合法性验证。
大家是否注意到，前面我们处理登录的函数中 有如下箭头所指的 一行代码
这行代码的作用 就是在登录认证后，将 用户类型保存到session数据中， 也就是存入前面数据库的那张图的 会话数据记录中。
Django 框架 会自动在 HTTP 响应消息头中 加入 类似下面的 sessionid cookie
后续的HTTP请求就会携带这个sessionid，
我们处理 URL 以 /api/mgr 开头的 API 请求 代码里面， 需要 加上一个验证逻辑。
验证请求的cookie里面是否有sessionid，并且检查session表，看看是否存在session_key为该sessionid 的一条记录，该记录的数据字典里面是否 包含了 usertype 为 mgr 的 数据。
前面实现的代码中， 这些请求都是在dispatcher入口函数处理的，我们就只需在该dispatch中进行验证。
修改 mgr/customer.py 的dispatcher 函数，在前面加上如下代码
# 根据session判断用户是否是登录的管理员用户
if 'usertype' not in request.session:
return JsonResponse({
'ret': 302,
'msg': '未登录',
'redirect': '/mgr/sign.html'},
status=302)
if request.session['usertype'] != 'mgr' :
return JsonResponse({
'ret': 302,
'msg': '用户非mgr类型',
'redirect': '/mgr/sign.html'} ,
status=302)
注意request对象里面的session属性对应的就是 session记录里面的 数据。
该数据对象类似字典，所以检查是否有usertype类型为mgr的信息，就是这样写
目前为止，我们项目代码，在如下百度网盘中的 bysms_07.zip
百度网盘链接：https://pan.baidu.com/s/1nUyxvq6IYykBNtPUf4Ho6w
提取码：9w2u
这里面的前端代码包含了用户登录的界面，登录地址为 http://localhost/mgr/sign.html
作业和练习
根据课程内容，仔细体会 session机制的原理。
在上次作业代码的基础上，加上对 API 接口请求消息，检查 对应用户是否登录。
写好后端代码后，使用requests库，自己测试一下，后端代码 是否能够正确处理 没有登录的请求。