django rest framwork api guid 关于认证的有这么多种方式
先看默认的 authentication api guid
REST_FRAMWORK:{ } 是整个django rest framwork 整个的变量配置中心
SessionAuthentication实际上是使用了django里面的sessionMiddleware
每当一个request 进来的时候，这两个meddleware就会将我们的cookie里的session_id转换成request.user
rest_framework/authentication.py源码解读:
其中的antuenticate 就是从我们的request中取出的user，实际上还依赖的是我们django 自带的session 机制
django rest framwork 给我们提供了三种不同的认证模式
sessionAuthentication 常用的是浏览器当中，因为浏览器会自动的设置cookie。并将cookie和session带到我们的服务器当中，所以前后端分离的系统我们很少用到这种。
重点是 tokenAuthentication
下面我们来介绍下 tokenAuthentication
ps: 所有有表的app 都要添加到 install_apps 里面 来，不然migration 的时候会报错，不会帮我们生成数据库表的
添加apps 后，接下来我们进行migration migrate ，进入数据库我们看到生成了一张authtokne_token 的表
这里面的 user_id 是一个外键，是指向到我们的userprofile 里面的
然后再来配置url (这个主要是生成token的一个url)
接下来我们就用postman 模拟请求这个url
这样我们就生成一个token了
下一步，怎么拿到token？
加一行
断点调试，是可以获取到用户的user 信息的
request.data 中存放着用户从前端post 过来的数据，request只将post和field中的东西放在我们的data中
head中设置的token 会被放进request auth 中
想要知道用户传递过来的auth 时只需要request.auth
django源码中的sessionMiddleware中有一个process_request方法
和一个process_response方法。
django/contrib/sessions/middleware.py:
但是django rest framwork 是有很多的弊端的：
1、因为django rest framwork 生成的token是保存在一台服务器上的，如果后续我们要做分布式系统或者两套系统共用一套token认证，那么就要实时的同步用户信息，这样就很麻烦
2、这种认证模式没有过期时间，安全性很低！
因此我们后续就引进了 jwt 认证模式 json web token