这是一个创建于 1704 天前的主题，其中的信息可能已经有所发展或是发生改变。
session 最大的问题在于没有办法降级。
JWT 降级的手段就很多了，Redis 用来做补偿，比如生命周期的管理。踢掉用户等等...
基于 JWT 的方案对不 session 还有什么缺点呢？
 |
1
bolide2005 2020-04-26 18:27:28 +08:00
是说每次业务鉴权都要依赖 redis 吗？在 redis 记录发出去的 jwt ？或者是在 redis 里记录作废的 jwt ？好像和 token 这个东西设计的初衷不太一致……
|
 |
2
also24 2020-04-26 18:28:57 +08:00 via Android
|
|
3
also24 2020-04-26 18:35:56 +08:00 via Android
我猜测楼主的思路是：
使用 JWT 做基础的鉴权，同时使用 Redis 做补充管理（例如通过黑名单的方式提前吊销某 token ） 但这样其实抛弃了 JWT 或者说 Client side session 的不少优势： Redis 的引入导致需要依赖服务端。 服务端的引入导致需要专门处理 session 共享。 以及，如果想实现完整的生命周期管理，黑名单未必够用，可能需要引入白名单，此时这个方案实际上已经变成了 Server side session 了。 |
 |
4
xiadada OP @also24 是变成服务端 session 了， 但是如果 Redis 挂了（只是一个服务端依赖的代表），不影响正常业务走下去， 而 Redis 挂了是小概率事件。 这套方案可以保证原来的 session 服务一定不挂。 最后一点一定不挂很吸引人啊。
|
|
5
also24 2020-04-26 18:46:36 +08:00 via Android
@xiadada
所谓 “一定不挂”，其实对应的是 “ session 管理未必生效” ，这是非常不严谨的。 如果你做了 session 管理功能，就不应该让它处于一种不确定是否能用的状态。 从这个角度来看，如果 Redis 挂了，那理应将整个 session 认证部分停掉，而不是 “带伤上阵” 。 |
|
6
xiadada OP @also24 我能 get 到你的点， 但是在业务上，我们是希望能有降级方案的。 我的管理功能只是 3 个 9，但是「校验」用户身份的功能可以做到 100%可靠。
|
|
7
also24 2020-04-26 18:53:07 +08:00 via Android  1
当然，并不是说完全否定这种模式，如果有这种不太严谨的业务场景，那用用倒也无妨。
本质上来说，其实就是分了两种状态。 在日常状态下，将 client side session 的 session data 作为 server side session 的 session id 使用。 在 Redis 挂掉等奇怪的状态下，退化为完全使用 client side session 机制。 |
Select Language