DingTalkDemo 52013

javademo下载了一段时间，在企业钉钉后台都部署配置了。运行进去第一次能把当前登录者信息取到，继续刷新页面，直接报52013错误，气愤的不行。隔了一段时间（大概两小时），又能运行成功一次，持续刷新index.jsp，错误码依旧。怀疑是authcode作怪，逛了不少论坛贴吧，没啥有用的。突然发现，授权的请求是ajax get请求，极有可能是缓存导致生成不了最新的authcode。然后将url改成url : _ctx+'/userinfo?code=' + info.code + '&corpid=' + _config.corpId+"&now="+new Date().getTime() 常用的去除缓存方法，运行demo就正常。另一个地方AuthHelper类getJsapiTicket方法分支条件改成if (true || jsTicketValue == null || curTime - jsTicketValue.getLong("begin_time") >= cacheTime)，让Demo每次运行获取最新的Ticket。菜鸟一枚，最烦这个半成品demo，浪费精力，demo编写者就不能花点时间把例子测试一下再传上去，编码态度真是堪忧！！

展开

收起

酱油乐土 2016-08-10 09:41:04 6054 0

4 条回答

写回答

取消提交回答

虞城流氓

回 1楼钉钉-赤司的帖子
大神啊，52013，签名检验失败，到底服务器端的signature是跟客户端的什么对比才报出这个问题的，麻烦给一个测试工具，或者帮助啊。万分感谢！！！！！！

2017-05-19 14:19:52

赞同展开评论打赏
如_意

回 2楼君信的帖子
这种方案有可能会出现时间错位而导致过期的情况。比如手机端向服务端发起了签名请求，这时jsticket还没有过期，比如在59分59秒的时候，签名完成后，响应到前端，由于网络较慢可能超过了1秒钟才返回到前端，而服务端因为jsticket已经达到了1小时于是自动发起了更新，服务端更新了新的jsticket，这时前端才收到签名返回的结果，于是在前端再验证时将会导致52013错误，鉴权失败。
-------------------------

ReDingTalkDemo 52013
经测试后猜测，钉钉签权的过程，钉钉手机端的微应用端会保留jsticket，当我们进入微应用页面时，由于jsticket过期，后端将会自动请求新的jsticket来签名，然后将签名包返回，这时钉钉手机端的微应用端却没有即时的更新最新的jsticket，导致签名失败，抛52013的错误。
在手端jsticket没有更新的情况下，过一段时间后再打开前端，就有可能会签名成功。
可能的原因是签名包的本地验证必须要有最新的jsticket，但钉钉手机端的微应用端似乎没有很好的即时同步到。

2017-03-29 15:17:22

赞同展开评论打赏
君信

您好，52013错误是签名校验失败的错误，跟authcode没有关系，并且authcode是jsapi返回的，跟缓存没有关系。
最好也不要每次都去访问都去获取新的jsticket，因为新的jsticket生成会导致老的jsticket过期，假如有多人访问的话，很出现导致52013（签名校验失败）

之所以出现你描述的这个问题，很有可能是jsticket过期了

我的建议是:
集中管理jsticket，比如起一个后台线程，每一个小时去获取一次jsticket，保证jsticket的唯一性，这么做比较好。

2016-08-10 16:35:51

赞同展开评论打赏
钉钉-赤司

非常感谢，我们会及时更新Demo的

2016-08-10 12:55:54

赞同展开评论打赏

DingTalkDemo 52013

相关文章

相关电子书