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

前言

前段时间整理的文章：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.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避坑的资料请关注服务器之家其它相关文章！

原文链接：https://juejin.cn/post/7102389025050361864