用户鉴权
定义
验证用户是否合法以及验证用户的权限
###常用认证
密码认证、短信认证、动态口令、人脸识别。。。
用户验证
后端常用鉴权方式
- HTTP Basic Authentication
这种授权方式是浏览器遵守http协议实现的基本授权方式,HTTP协议进行通信的过程中，HTTP协议定义了基本认证认证允许HTTP服务器对客户端进行用户身份证的方法。
####认证过程
1． 客户端向服务[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cjRdOCTk-1583730483091)(…/AppData/Roaming/Typora/typora-user-images/image-20200306214446133.png)]器请求数据，请求的内容可能是一个网页或者是一个其它的MIME类型，此时，假设客户端尚未被验证，则客户端提供如下请求至服务器:
Get /index.html HTTP/1.0
Host:www.google.com
2． 服务器向客户端发送验证请求代码401,服务器返回的数据大抵如下：
HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm=“google.com”
Content-Type: text/html
Content-Length: xxx
3． 当符合http1.0或1.1规范的客户端（如IE，FIREFOX）收到401返回值时，将自动弹出一个登录窗口，要求用户输入用户名和密码。
4． 用户输入用户名和密码后，将用户名及密码以BASE64加密方式加密，并将密文放入前一条请求信息中，则客户端发送的第一条请求信息则变成如下内容：
Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx
注：xxxx…表示加密后的用户名及密码。
5． 服务器收到上述请求信息后，将Authorization字段后的用户信息取出、解密，将解密后的用户名及密码与用户数据库进行比较验证，如用户名及密码正确，服务器则根据请求，将所请求资源发送给客户端：
####BASIC认证的缺点
HTTP基本认证的目标是提供简单的用户验证功能，其认证过程简单明了，适合于对安全性要求不高的系统或设备中，如大家所用路由器的配置页面的认证，几乎 都采取了这种方式。其缺点是没有灵活可靠的认证策略，如无法提供域（domain或realm）认证功能，另外，BASE64的加密强度非常低，可以说仅 能防止sohu的搜索把它搜到了。当然，HTTP基本认证系统也可以与SSL或者Kerberos结合，实现安全性能较高（相对）的认证系统 - session-cookie
这个方式是利用服务器端的session（会话）和浏览器端的cookie来实现前后端的认证
原理举例
- 小明访问某一网站example.com的登录页面，此时通过浏览器发了一个http request请求，此时http header头域的cookie值可以是空的
- xx.com服务器收到这个请求，并接受了小明提交过来的登录数据，判断用户名和密码都正确，这个时候服务器会“种下一个cookie”一般是将小明的用户名发送给客户端，通常是“Set-Cookie: session-id=12345;”这个字符串通过http response返回给客户端（浏览器）
- 浏览器收到http response返回来的信息发现cookie了，然后将信息写入到浏览器的某个存储文件中去
- 小明再访问xx.com的其他页面的时候，请求的http header中会带着这个cookie，
- 服务器端程序会找cookie，并根据cookie取出客户端想要的信息并返回给客户端
session的调用机制
1）用户请求服务端程序login.php填写数据后提交
2）服务器收到提交的数据取得用户信息，将用户信息存入session，并将session_id通过cookie的形式发给客户端
3）客户端将session_id存入浏览器cookie文件
4）用户再次访问其他页面时，将有session_id的cookie通过header头发给服务端
5）服务端拿到session_id从session中取到用户信息并返回
- Token
- 流程
- 客户端使用用户名跟密码请求登录
- 服务端收到请求，去验证用户名与密码
- 验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
- 客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
- 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
- 服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
- token与session的区别
局限性
时效性
可扩展性 - JWT
- 定义
JWT是Auth0提出的通过对JSON进行加密签名来实现授权验证的方案，就是登陆成功后将相关信息组成json对象，然后对这个对象进行某中方式的加密，返回给客户端，客户端在下次请求时带上这个token，服务端再收到请求时校验token合法性，其实也就是在校验请求的合法性。 - 组成
Headers、playload、Signature、jwt
- OAuth(开放授权)：如QQ登录
OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容，为了保护用户数据的安全和隐私，第三方网站访问用户数据前都需要显式的向用户征求授权
用户权限验证
权限管理
权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源
权限管理好比如钥匙，有了钥匙就能把门打开，但是权限设置是有级别之分的，假如这个系统有多个权限级别就如一间屋有多个门，想要把所有门都打开您必须要取得所有的钥匙，就如系统一样。
###django permission
- 权限机制
- 权限项
Django 用 permission 对象存储权限项，每个model默认都有三个permission，即 add model, change model 和 delete model
permission 总是与 model 对应的，如果一个 object 不是 model 的实例，我们无法为它创建/分配权限 - 权限应用
- 查看权限
列出用户的所有权限
user.get_all_permissions()
列出用户所属group的权限
user.get_group_permissions()- 添加权限
user.user_permissions.add(permission, permission, …)- 删除权限
user.user_permissions.remove(permission, permission, …)- 清空权限
user.user_permissions.clear()- 权限验证
当业务逻辑中涉及到权限检查时，decorator 能够分离权限验证和核心的业务逻辑，使代码更简洁，逻辑更清晰。permission 的 decorator 为permission_required
装饰器
from django.contrib.auth.decorators import permission_required
@permission_required(’dashboard.view_server')
def my_view(request):
...
在类视图中验证
from django.utils.decorators import method_decorator
from django.contrib.auth.decorators import login_required, permission_required
class ServerView(TemplateView):
@method_decorator(login_required)
@method_decorator(permission_required(“dashboard.view_server”)
def get(self, request, *args, **kwargs):
……
非装饰器
if not request.user.has_perm(’dashboard.view_server')
return HttpResponse('Forbidden')
has_perm() 方法的参数，即 permission 的 codename，但传递参数时需要加上 model 所属 app 的前缀，无论 permission 赋予 user 还是 group，has_perm()方法均适用
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
