最近常看到一些关于 JWT、Session、Toen 提问的帖子,他们之间的关系也没了解过,因为一上手就是用的 JWT 和 Token,感觉 Session 和 Cookie 是很古老的东西了,所以就从实战的角度理解下他们的关系
Session + Cookie 实现鉴权认证
验证码获取接口
1 |
|
登录接口
1 |
|
拦截器验证 Cookie
定义拦截器
1 |
|
注册拦截器
1 |
|
WebMvcConfigurerAdapter
在 Spring 5.0 版本中被弃用,建议使用新的方式来进行 Spring MVC 的配置,可以实现 WebMvcConfigurer
接口并重写其中的方法
普通的业务接口
1 |
|
模拟流程
不登录请求
先不登录,直接请求业务接口
获取验证码
登录
查看请求详情可以看到返回的 cookie
重新请求
重新请求响应成功,并且可以在请求详情中看到前面登录返回的 cookie
JSESSIONID
可以发现上面除了自己生成的 cookie 外,还有一个名为 JSESSIONID
的 cookie
对于 Tomcat 容器来说,当服务端的 session 被创建时,Response 中自动添加了一个 Cookie:JSESSIONID:xxxx,在后续的请求中,浏览器也是自动的带上了这个 Cookie,服务端根据 Cookie 中的 JSESSIONID 取到了对应的 session。这验证了一开始的说法,客户端服务端是通过 JSESSIONID 进行交互的,并且,添加和携带 key 为 JSESSIONID 的 Cookie 都是 Tomcat 和浏览器自动帮助我们完成的,这很关键
Session 的持久化
默认情况下,SpringBoot 是不会持久化 Session 的,这时重启服务后,session 都会失效,所以需要持久化 Session
session 的持久化可以使用 Mysql 或者 Redis,这里示例为了方便,就持久化到本地
增加配置
1 | server.servlet.session.persistent = true |
注意:因为持久化到本地需要使用 Java 的序列化与反序列化方案,所以这里的 User 类需要实现 Serializable 接口并定义 serialVersionUID
JWT + Token 实现鉴权认证
整理上的登录验证流程与前面大差不差,主要是不使用 Session 和 Cookie,使用 token 替代
登录接口
登录接口在鉴权成功后,使用 JWT 生成 Token,将 Token 缓存到 Redis 中并返回
1 | /** |
拦截器校验 Token
与前面不同的是,token 是放到请求头里,然后通过 redis 获取 token 与之对应的 user
自定义注解获取当前用户
自定义注解
1 |
|
通过实现 SpringMVC 的 HandlerMethodArgumentResolver
接口,获取当前请求用户并解析到接口中
1 |
|
工具类获取当前登录用户
1 |
|
Sa-Token
Sa-Token 自称可能是史上功能最全的 Java 权限认证框架!目前已集成——登录认证、权限认证、分布式 Session 会话、微服务网关鉴权、单点登录、OAuth2.0、踢人下线、Redis 集成、前后台分离、记住我模式、模拟他人账号、临时身份切换、账号封禁、多账号认证体系、注解式鉴权、路由拦截式鉴权、花式 token 生成、自动续签、同端互斥登录、会话治理、密码加密、jwt 集成、Spring 集成、WebFlux 集成…
Sa-Token 实现登录
1 |
|