关于Access_Token的expires_in判定问题

315830013 发布于 2016/10/30 17:39
阅读 1K+
收藏 0

@JFinal 你好,想跟你请教个问题:根据微信的API文档 同一个Access_Token的过期时间应该是一样的 而在开发过程中我发现一个问题 同一个Access_Token的过期时间会被错误的延长 导致Access_Token的可用性判断出错 附图

返回当前使用的AccessToken与过期时间

可以看到Access_Token的过期时间被延长了。。


加载中
1
315830013
315830013

刚才自己debug了一下 发现了出现该问题的地方

此处从缓存中去取出了access_token的json字符串 并以此构造一个AccessToken的类 然而AccessToken的构造方式

expires_Time是根据系统当前时间进行更新的。。


JFinal
JFinal
回复 @315830013 : expire_in 是微信服务端给的一个过期“时长”,这里注意是“时长”,不是具体的过期时间。在开发这段代码的时候,微信给的是 7200 秒,那么这段代码是没有问题的
0
JFinal
JFinal
为什么被延长了? 是微信服务端的 bug ? 
315830013
315830013
不是微信服务端的Bug。。是Access_Token的构造方式与Access_Token缓存配合时出现的Bug
0
315830013
315830013

举个例子就是 

18:00时第一次获取access_token 此时的token是通过调用微信API得到的 过期时间是20:00 程序将该结果的json存入缓存中 

18:10时第二次获取access_token 此时程序从缓存中取出token的json字符串 并构造AccessToken 此时expires_in的计算结果会是20:10 但实际上微信服务器上该token的过期时间是20:00

0
JFinal
JFinal

引用来自“315830013”的评论

举个例子就是 

18:00时第一次获取access_token 此时的token是通过调用微信API得到的 过期时间是20:00 程序将该结果的json存入缓存中 

18:10时第二次获取access_token 此时程序从缓存中取出token的json字符串 并构造AccessToken 此时expires_in的计算结果会是20:10 但实际上微信服务器上该token的过期时间是20:00

expire_in 是微信服务端给的一个过期“时长”,这里注意是“时长”,不是具体的过期时间。在开发这段代码的时候,微信给的是 7200 秒,那么这段代码是没有问题的
0
315830013
315830013

引用来自“315830013”的评论

举个例子就是 

18:00时第一次获取access_token 此时的token是通过调用微信API得到的 过期时间是20:00 程序将该结果的json存入缓存中 

18:10时第二次获取access_token 此时程序从缓存中取出token的json字符串 并构造AccessToken 此时expires_in的计算结果会是20:10 但实际上微信服务器上该token的过期时间是20:00

引用来自“JFinal”的评论

expire_in 是微信服务端给的一个过期“时长”,这里注意是“时长”,不是具体的过期时间。在开发这段代码的时候,微信给的是 7200 秒,那么这段代码是没有问题的

第一次构造AccessToken时是没有问题的 因为此时构造AccessToken的json字符串是从微信服务器返回的 此时微信给的7200秒是指这个token在微信服务器上产生到失效的时长 此时expiredTime的计算没有问题

但是第二次构造AccessToken时 JFinal会从AccessToken的缓存中取出之前的到的JSON字符串用来构造AccessToken 此时计算出的expiredTime就是错误的了。。

很抱歉题目可能表达错意思了。。

JFinal
JFinal
回复 @315830013 : 现在用户量非常大,必然会越做越好, jfinal 2.3 也会在 12 月份发布,确保四连冠
315830013
315830013
回复 @JFinal : 这个框架我从大二就在用了 一直觉得这是一个很优秀的框架 希望这个框架能越做越好
如梦技术
如梦技术
回复 @JFinal : 恩恩,看明白了。
JFinal
JFinal
呼叫下大神 @如梦技术 看这块有没有问题,最近很忙暂时没有时间看代码,感谢反馈
返回顶部
顶部