若依微服务版本中哪里使用到了刷新redis缓存10分钟 若依session

我们都知道Web身份校验有三种主要形式：Cookie，Session，Token。其中Cookie和Session都是有状态登录，而Token是无状态登录。

1.什么是有状态登录？

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如 Tomcat 中的 Session。例如登录：用户登录后，我们把用户的信息保存在服务端 session 中，并且给用户一个 session-id 存到cookie ，记录对应的 session，然后下次请求，用户携带 cookie 值来（这一步由浏览器自动完成），我们就能识别到对应 session，从而找到用户的信息。这种方式目前来看最方便，但是也有一些缺陷，如下：

• 服务端保存大量数据，增加服务端压力
• 服务端保存用户状态，不支持集群化部署

2. 什么是无状态登录

微服务集群中的每个服务，对外提供的都使用 RESTful 风格的接口。而 RESTful 风格的一个最重要的规范就是：服务的无状态性，即：

• 服务端不保存任何客户端请求者信息
• 客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份

那么这种无状态性有哪些好处呢？

• 客户端请求不依赖服务端的信息，多次请求不需要必须访问到同一台服务器
• 服务端的集群和状态对客户端透明
• 服务端可以任意的迁移和伸缩（可以方便的进行集群化部署）
• 减小服务端存储压力

3. 无状态登录的实现

无状态登录的流程：

1. 首先客户端发送账户名/密码到服务端进行认证
2. 认证通过后，服务端将用户信息加密并且编码成一个 token，返回给客户端
3. 以后客户端每次发送请求，都需要携带认证的 token
4. 服务端对客户端发送来的 token 进行解密，判断是否有效，并且获取用户登录信息

说白了，唯一的差别就是客户端信息的存储位置，session存储在服务端，token存储在客户端；而又因为token存储在客户端，所以服务端发送和接受token的时候，需要通过对用户信息进行加密和解密。

4. session与token优缺点

使用 session 最大的优点在于方便。你不用做过多的处理，一切都是默认的即可。

但是使用 session 有另外一个致命的问题就是如果你的前端是 Android、iOS、小程序等，这些 App 天然的就没有 cookie，如果非要用 session，就需要这些工程师在各自的设备上做适配，一般是模拟 cookie，从这个角度来说，在移动 App 遍地开花的今天，我们单纯的依赖 session 来做安全管理，似乎也不是特别理想。

这个时候 JWT 这样的无状态登录就展示出自己的优势了，这些登录方式所依赖的 token 你可以通过普通参数传递，也可以通过请求头传递，怎么样都行，具有很强的灵活性。

不过话说回来，如果你的前后端分离只是网页+服务端，其实没必要上无状态登录，基于 session 来做就可以了，省事又方便。

5 JWT

5.1 简介

JWT，全称是 Json Web Token ， 是一种 JSON 风格 的轻量级的授权和身份认证规范，可实现无状态、分布式的 Web 应用授权：

图片
JWT 作为一种规范，并没有和某一种语言绑定在一起，常用的 Java 实现是 GitHub 上的开源项目 jjwt，地址如下：https://github.com/jwtk/jjwt

5.2 JWT 数据格式

JWT 包含三部分数据：

1. Header：头部，通常头部有两部分信息：

• 声明类型，这里是JWT
• 加密算法，自定义
  我们会对头部进行 Base64Url 编码（可解码），得到第一部分数据。

2. Payload：载荷，就是有效数据，在官方文档中(RFC7519)，这里给了 7 个示例信息：

• iss (issuer)：表示签发人
• exp (expiration time)：表示token过期时间
• sub (subject)：主题
• aud (audience)：受众
• nbf (Not Before)：生效时间
• iat (Issued At)：签发时间
• jti (JWT ID)：编号
  这部分也会采用 Base64Url 编码，得到第二部分数据。

3. Signature：签名，是整个数据的认证信息。一般根据前两步加密字符串，再加上服务的的密钥 secret（密钥保存在服务端，不能泄露给客户端），通过 Header 中配置的加密算法生成。用于验证整个数据完整和可靠性。
   secret一旦泄密，客户端可以自我签发jwt了！

5.3 JWT 交互流程

流程图：

步骤翻译：

1. 应用程序或客户端向授权服务器请求授权
2. 获取到授权后，授权服务器会向应用程序返回访问令牌
3. 应用程序使用访问令牌来访问受保护资源（如API）

因为 JWT 签发的 token 中已经包含了用户的身份信息，并且每次请求都会携带，这样服务的就无需保存用户信息，甚至无需去数据库查询，这样就符合了 RESTful 的无状态规范。

5.4 JWT 存在的问题

说了这么多，JWT 也不是天衣无缝，由客户端维护登录状态带来的一些问题在这里依然存在，举例如下：

1. 续签问题，这是被很多人诟病的问题之一，传统的 cookie+session 的方案天然的支持续签，但是 jwt 由于服务端不保存用户状态，因此很难完美解决续签问题，如果引入 redis，虽然可以解决问题，但是 jwt 也变得不伦不类了。
2. 注销问题，由于服务端不再保存用户信息，所以一般可以通过修改 secret 来实现注销，服务端 secret 修改后，已经颁发的未过期的 token 就会认证失败，进而实现注销，不过毕竟没有传统的注销方便。
3. 密码重置，密码重置后，原本的 token 依然可以访问系统，这时候也需要强制修改 secret。
4. 基于第 2 点和第 3 点，一般建议不同用户取不同 secret。

6. 手撕若依源码

打开TokenService，这是负责token验证的一个类。

6.1 属性讲解

首先是我们之前讲过的header，生成signature的secret以及payload中包含的过期时间，可以看到这边是从配置文件读的，我们打开application.yml就可以看到配置

6.2 生成 & 获取token

我们先从这两个方法开始

它是调用Jwts的方法，传入Claims，设置编码方式以及secret，从而生成token令牌；

这里我们获取token的值，注意这里的header不是指的是request里的全部header，而是前面6.1里写的那个配置文件里的token！也就是读的是header里key为如果token不为空并且token是以onstants.TOKEN_PREFIX)开头的，我们就将token的前缀删掉，然后返回。

我们打开这个TOKEN_PREFIX，发现它是自定义常量类中的一个常量。

并且还有其他三个常量，一会儿都会用得到。我们接着打开前端，查一下这个Bearer，成功找到了它使用的位置，也就是前端每次传递Authorization的时候，都会用这个前缀和getToken的结果进行拼接，方便与后端进行验证。

6.3 获取用户身份信息 & 生成令牌

接着我们回到第一个方法

调用刚刚的getToken方法并进行判空后，通过parseToken()从token中获取数据

这个是Jwts里面的方法，将secret以及token传入jwts解析器，获得token的body信息，是一个Claims类，看源码，可以理解为一个JSON。

这里作者读取了用户对应的权限以及用户信息，因为Claims的Value是Object类型，要强转成String。

获取到UUID以后，在前面拼接login_tokens得到redis登录用户的key，然后去redis缓存中找到用户。

6.4 刷新令牌有效期

当我们有用户用账号密码登录时，我们需要刷新他的令牌有效期。

我们能看到这个方法里重置了这个用户的登陆时间以及过期时间，并将用户的key缓存到Redis中。

7. JWT过滤器

上一篇博客提过一个token认证过滤器JwtAuthenticationTokenFilter，它的父类OncePerRequestFilter代表只会过滤一次。

首先通过request拿到token去Redis里找到缓存用户，方法是6里面讲过的。如果找到了用户并且用户权限不为空，去校验一下时间，如果时间相差不足20分钟，自动刷新缓存，保证令牌有效性。通过用户以及用户的权限去实例化账号密码权限Token，将request里的信息放入这个Token。最后将信息放入上下文里。