评论

收到了notify_third_fasteregister也收达authorized,悠哉?(小程序快速注册踩坑二)

收到了notify_third_fasteregister也收达authorized,事件先后顺序处理经验,踩坑记录啊。

【点子出来了】

帮忙快速注册完小程序后,登录用户小程序后台发现,已授权给服务商了。当时脑子一灵说,如果可以直接授权,有通知就可以在授权通知的地方自动关联通知的小程序和系统账号的归属关系。这个猜想是可行的。

【实现beta1】

于是开始在授权事件接收的地方,关联授权通知账号和系统绑定的关系。经过半天的代码实现,和单元测试,确认是可以自动处理的,于是发发版上线。

但是不断的接收用户反馈,并没成功自动关联两个系统。

【实现beta2】

调查发现,authorized早于notify_third_fasteregister。于是加了暂存区。

先返回的是授权导致不知道授权通知对应的公司,需要暂存授权资料,收到注册通知再去处理授权。还需要代码处理。

【实现beta3】

发现处理起来比较费劲儿,还要加入暂存区。写了一种兼容两种事件不区分先后到达的解决方案。发现比较不雅观。因为i通知事件并没给我是否是小程序,仅有一个appid,我也无法区分是否该appid来自快速注册。虽然有以下的实现效果。

【beta4】

于是询问官方,希望能知道事件确定的顺序。官方建议延迟1分钟处理。于是我就加上了延迟一分钟的方案。


【beta5】

上线后授权后自动处理很灵,但是发现微信不停的给我发授权通知和注册通知。因为我是用的上图第一种,同步延迟,很久没有回复微信消息,微信就不停的给我发。当我查看日志的时候, 马上决定把同步改成异步延迟。

【beta6】

为了使得我只缓存小程序类型,我获取了一次小程序信息,并判断了是否有id=17的权限(开发与账号管理权限),结果该接口产生了新token我未更新,导致公众号和小程序大批的token失效。于是就把过滤条件删掉了。

【beta7】

InfoType authorized先到时,加入一个延迟75s的异步线程,然后在InfoType notify_third_fasteregister到达时,记录appid和系统账号关系,并记录下appid,然后等异步处理时间可行时,即可拿到关联的账号绑定。

并约定原则,如果产生一次token就要更新数据区,这样保证了一次产生后一定被保存。

然后再后续资料完善时,配置小程序webview域名,request域名,然后提交代码,提交审核。可与保证全程自动化。

但是这里面一个前提是,微信必须要在认证状态,授权状态发生变化时,给服务商发送通知。

因为对微信的稳定性相对比较信任,就没想过会有一天,会收不到通知的情况,这就是下一讲续集。

如果未收到通知,会怎样?

难道还会存在,设置了名字,却还是提升无名字和类目,请完善资料再提交代码?

如何可以保证自动的处理代码?



最后一次编辑于  2020-12-14  
点赞 1
收藏
评论
登录 后发表内容