Luffy之登录认证以及JWT

1.用户认证

在前面我们已经完成了,前端登录页面的搭建,以及路由分配,现在我们作关于登录认证部分的东西

Django提供了认证系统。认证系统包含：

• 用户

• 权限：二元（是/否）标志指示一个用户是否可以做一个特定的任务。

• 组：对多个用户运用标签和权限的一种通用的方式。

• 一个可配置的密码哈希系统

• 用户登录或内容显示的表单和视图

• 一个可插拔的后台系统

Django默认用户的认证机制依赖Session机制，我们在本项目中将引入JWT认证机制，将用户的登陆状态[认证信息]存放在Token字符串中，然后对接Django的认证系统，帮助我们来实现：

• 用户的数据模型

• 用户密码的加密与验证

• 用户的权限系统

1.1 Django用户模型类

Django认证系统中提供了用户模型类User保存用户的数据，默认的User包含以下常见的基本字段：

• username

  必选。 150个字符以内。 用户名可能包含字母数字，_，@，+ . 和-个字符。在Django更改1.10：max_length从30个字符增加到150个字符。

• email

  可选（blank=True）。 邮箱地址。

• password

  必选。 密码的哈希及元数据。 （Django 不保存原始密码）。 原始密码可以无限长而且可以包含任意字符。

• groups

  与Group 之间的多对多关系。

• user_permissions

  与Permission 之间的多对多关系。

• is_staff

  布尔值。 指示用户是否可以访问Admin 站点。

• is_active

  布尔值。 指示用户的账号是否激活。 我们建议您将此标志设置为False而不是删除帐户；这样，如果您的应用程序对用户有任何外键，则外键不会中断。它不是用来控制用户是否能够登录。 在Django更改1.10：在旧版本中，默认is_active为False不能进行登录。

• is_superuser

  布尔值。 指定这个用户拥有所有的权限而不需要给他们分配明确的权限。

• last_login

  用户最后一次登录的时间。

• date_joined

  账户创建的时间。 当账号创建时，默认设置为当前的date/time。

常用方法：

• set_password(raw_password)

  设置用户的密码为给定的原始字符串，并负责密码的。 不会保存User 对象。当None为raw_password 时，密码将设置为一个不可用的密码。

• check_password(raw_password)

  如果给定的raw_password是用户的真实密码，则返回True，可以在校验用户密码时使用。

管理器方法：

管理器方法即可以通过User.objects. 进行调用的方法。

• create_user(username, email=None, password=None, **extra_fields)

  创建、保存并返回一个User对象。

• create_superuser(username, email, password, **extra_fields)

  与create_user() 相同，但是设置is_staff 和is_superuser 为True。

2 创建自定义的用户模型类

Django认证系统中提供的用户模型类及方法很方便，我们可以使用这个模型类，但是字段有些无法满足项目需求，如本项目中需要保存用户的手机号，需要给模型类添加额外的字段。

Django提供了django.contrib.auth.models.AbstractUser用户抽象模型类允许我们继承，扩展字段来使用Django认证系统的用户模型类。

我们可以在apps中创建Django应用users，并在配置文件中注册users应用。

在创建好的应用models.py中定义用户的用户模型类。

我们自定义的用户模型类还不能直接被Django的认证系统所识别，需要在配置文件中告知Django认证系统使用我们自定义的模型类。

在settings.py配置文件中进行设置

AUTH_USER_MODEL 参数的设置以点.来分隔，表示应用名.模型类名。

注意：Django建议我们对于AUTH_USER_MODEL参数的设置一定要在第一次数据库迁移之前就设置好，否则后续使用可能出现未知错误。

执行数据库迁移

1.3 Django REST framework JWT

在用户注册或登录后，我们想记录用户的登录状态，或者为用户创建身份认证的凭证。我们不再使用Session认证机制，而使用Json Web Token认证机制。

1.3.1 JWT的构成

JWT就一段字符串，由三段信息构成的，将这三段信息文本用.链接一起就构成了Jwt字符串。就像这样:

第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature).

1.3.2 header

jwt的头部承载两部分信息：

• 声明类型，这里是jwt

• 声明加密的算法 通常直接使用 HMAC SHA256

完整的头部就像下面这样的JSON：

然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.

1.3.3 payload

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分

• 标准中注册的声明

• 公共的声明

• 私有的声明

标准中注册的声明 (建议但不强制使用) ：

• iss: jwt签发者

• sub: jwt所面向的用户

• aud: 接收jwt的一方

• exp: jwt的过期时间，这个过期时间必须要大于签发时间

• nbf: 定义在什么时间之前，该jwt都是不可用的.

• iat: jwt的签发时间

• jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。

公共的声明 ： 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密.

私有的声明 ： 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

定义一个payload:

然后将其进行base64加密，得到JWT的第二部分。

1.3.4 signature

JWT的第三部分是一个签证信息，这个签证信息由三部分组成：

• header (base64后的)

• payload (base64后的)

• secret

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。

将这三部分用.连接成一个完整的字符串,构成了最终的jwt:

**注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。**

关于签发和核验JWT，我们可以使用Django REST framework JWT扩展来完成。

文档网站http://getblimp.github.io/django-rest-framework-jwt/

http://getblimp.github.io/django-rest-framework-jwt/

安装

settings.py的配置代码中

JWT_EXPIRATION_DELTA 指明token的有效期

1.3.6 使用

Django REST framework JWT 扩展的说明文档中提供了手动签发JWT的方法

在用户注册或登录成功后，在序列化器中返回用户信息以后同时返回token即可。

默认情况下，djangorestframework-jwt这个模块已经内置了一个登陆视图接口给我们了。我们直接使用

当前users的urls.py文件代码：

在总路由文件中，urls.py中注册子应用路由：

后端借口基本写完,现在我们在前端编写代码接收接口数据:

前端保存jwt

我们可以将JWT保存在cookie中，也可以保存在浏览器的本地存储里，我们保存在浏览器本地存储中

浏览器的本地存储提供了sessionStorage 和 localStorage 两种：

• sessionStorage 会话存储，浏览器关闭即失效

• localStorage 永久存储，长期有效

script发送axios以及回调函数处理的代码:

前台首页判断登录状态显示对应信息

header.vue

jwt后端认证(自定义)

Django REST framework JWT提供了登录签发JWT的视图，可以直接使用

但是默认的返回值仅有token，我们还需在返回值中增加username和user_id。

通过修改该视图的返回值可以完成我们的需求。

在users/utils.py 中，创建

修改settings.py配置文件