4

以下是我的理解,不知道是否正确:
1、登录成功后服务端会生成一个token作为唯一标示
2、token同时保存在后台数据库和客户端
3、客户端每次不用重新登录而是验证本地token和服务端token是否相等就可以
4、如果token过期就重新登录
还有一个问题,怎么实现token的时效性?如果token通过username、password生成,怎么才能使token在一段时间后过期?

Free 46
2018-08-21 提问
5 个回答
3

已采纳

不赞同3楼所说客户端不需要过期时间这个说法。

token应该是由服务端来最终决策,但前台也有必要了解过期时间,可以看一下我的token处理方式:

服务端: SQL/REDIS(减少数据库IO)  userid,token,expire,scope? 
// 后台expire最为简单 实时和当前时间戳进行比对 或者直接在数据库中 按照大于时间戳的筛选进行取出
手动设置过期 是在 取出后比较时间戳时需要做的, 可以直接将expire设置为0 或者删除行(不推荐) 可以写入服务器定期清理脚本中,使用Redis也是不错的选择

客户端: userid,token,expire |  tokens:{scope1:{token:'...',expire:150000000},scope2:{...}...}  
// 简单机制下 可以不需要scpoe(作用范围)

服务端不用说了,expire决定了token是否有效

而客户端最重要的是 有一个临期检查,最常用的场景就是 移动端的登录长期驻留,譬如说:
我们设定了30天的最长有效时间,同时我们的用户活跃频率在7天,
那么前台就可以去按周(灵活设置)的提前量去检查token ,如果用去 7/30的时间了,我们就在前台请求刷新token 这样就可以做到用户永久不登录的安全免登录. 当然 如果超过30天都没登录 这时候token过期 自然也就不能更新 需要手动登录了。

__ RE: 第三方token管理

关于第三方的token 其实要把自己的服务器当成是 客户端来理解就好了,逻辑是一致的,不过这里就一定存在scope了,以微信授权登录为例 我们拿到token的时候同时也会拿到 expires (有效时长) 那么我们要在自己的服务端存储成时间戳 time(true)+ expires*0.9 每次这样就可以 在token还未过期重新请求了。逻辑上和上面的客户端临检一致,实现上考虑到业务需求不同略有区别。

1

token中完全不必存储过期时间,什么时候过期由存储在服务端的token决定:服务端的token一般存储在类Redis的内存数据库中,时效由Redis控制。
当客户端发给服务token的时候,服务端会去redis检查是否有这个key(过期会被自动删除),从而实现了token的过期机制。顺便说一下,单点登录也可通过这个方式实现。

0

token 可以加密为可解密方式
存储数据为:

[
    'user_id'     => 1,
    'create_time' => 152378273,
]
对数组进行加密返回给客户端,服务端接口收到 Token 解密就可以了

撰写答案

你可能感兴趣的

推广链接