gtoken替换jwt实现sso登录的排雷避坑

2022-11-13 10:11:29 登录 替换 排雷

前言

前段时间整理的文章:gtoken替换jwt实现sso登录 | 带你读源码 收到了大家积极的反馈,gtoken替换jwt实现sso登录的开发过程是比较稳健的,但是在我们测试联调的过程中暴露出了很多问题。

如果大家也想使用gtoken替换jwt实现sso登录,那么这篇文章可以减少很多大家debug的时间,分享一下我的踩坑之旅。

gtoken

服务端出于优化项目体验的考虑,替换了之前校验登录状态的方式,由JWT替换为 Gtoken。

gtoken替换jwt解决的问题

  • 有效的避免了jwt服务端无法退出问题;
  • 解决jwt无法作废已颁布的令牌,只能等到令牌过期问题;
  • 通过用户扩展信息存储在服务端,有效规避了jwt携带大量用户扩展信息导致降低传输效率问题;

兼容JWT

gtoken替换jwt实现sso登录在前后端通信上是能做到兼容JWT的。

我们服务端的替换操作对前端同学应该是无感的,因为后端做了兼容处理,不需要前端同学修改任何东西。

gtoken实现原理

gtoken的实现原理以及如何使用建议大家读我这篇文章: gtoken替换jwt实现sso登录 | 带你读源码。

在本篇文章中就不赘述了,下面重点介绍踩坑之旅:

踩坑之旅

当大家遇到登录问题时可以从这几个方向定位问题:

1 gtoken版本

如果我们使用的版本是gf1.x.x,只能使用gtokenv1.4.X相关版本。

gtoken v1.5.0版本全面适配GoFrame v2.0.0。

如果遇到版本不一致的问题,比如提示这种:

可以通过指定gtoken版本解决,比如这样:

go get GitHub.com/goflyfox/gtoken@v1.4.1

如果我们是团队多人协作,碰到需要指定依赖版本的问题,我们可以考虑把go.mod提交到git中。

在遇到这个问题之前,我的习惯是把go.mod添加的gitignore中。

大家有没有更好的办法来解决需要指定依赖版本的问题呢

2 gtoken存储问题

如果你们的项目是集群应用,gtoken的存储就需要使用gRedis模式,而不是单机的GCache模式了。

这就需要我们生成token和获取token的各个项目连接的redis是一致的。

如果你是集群应用,千万要确保涉及到gtoken生成和验证的各个项目连接的redis是一致的。

所以,大家遇到token校验不通过时,可以首先排查一下配置文件,是不是连接redis库的问题。

3 不能跨环境使用token

正如上面提到的,如果gtoken的存储是使用redis中来实现集群项目的共享。

那我们是不能跨环境使用token的,因为我们的本机、开发、测试、预发布、生产等环境往往连接的是不同的redis。

4 测试账号不规范问题

如果测试时多个用户登录同一个账号,可能会出现奇葩问题。

究其原因是这样的:

gtoken是允许多点登录的,所以支持大家使用同一个账号登录。

但是!如果其中一个人做了退出登录的操作,那么其他人的登录态也会失效,需要重新登录。

比如设置的token有效期是2个小时,且2小时内有请求操作,会刷新token的有效期。但是如果有多人登录同一个账号,其中一个人退出,那么其他人的登录态也会失效的。

总结

  • gtoken版本问题
  • 连接的redis库不一致问题
  • 是否跨环境使用了token,导致校验不过的问题
  • 多人登录同一个账号,有退出操作,导致登录态失效的问题

上面这些是我在开发中踩的坑,大家如果在集成gtoken时遇到登录态问题可以从这几个角度排查问题,更多关于gtoken替换jwt登录sso避坑的资料请关注其它相关文章!

相关文章