前言
前段时间整理的文章: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/[email protected]
如果我们是团队多人协作,碰到需要指定依赖版本的问题,我们可以考虑把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避坑的资料请关注脚本之家其它相关文章!