5月8日微信小程序有公布了一个新功能:获取群ID和群名称等群信息,官方有一句话是这么介绍它的用处的:
现在,通过最新的接口能力,开发者可以通过群ID判断用户是否来自同一个微信群,同一个群内的用户之间可以更好地使用小程序进行协作,例如共同编辑文档、协同合作、共同点餐等等。
这么说的话,Nodes小程序也许能玩点什么新花样:
于是花叔马上打开开发工具做了一下预研,总结一下,用法很简单:
第一步.在app.js的onLaunch事件里获取shareTicket
第二步.在需要获取群信息(id或者群名称)的地方执行getShareInfo方法,并把shareTicket传进去
然后你就能把小程序分享到某个群里,别人打开的时候就能获取相关的群信息了,注.群id会以加密的方式放在回调函数的参数中的encryptedData里,这个密文一般是传送到服务端,然后服务端用对应的解密方法来解密,这样才能获取群ID,具体解密方法可以参考 https://mp.weixin.qq.com/debug/wxadoc/dev/api/signature.html
说完用法,我们来用扯扯这东西有什么用处,这个新能力有些同学不一定看得懂,花叔来总结一下:它只是做了一个更严谨的权限限制。什么意思呢?
拿官方提到的三类应用来举例
共同编辑文档、协同合作、共同点餐
在这能力出来前,这三种应用能做吗?能!腾讯投票就是很好的例子。
那么为什么小程序官方还要更新这个能力呢?
在这能力出现前,我们要做协同合作类的小程序应用的话,往往遵循的程序设计思路是:
新建一个事件(具备了一个唯一id)->传播一个带有这个id的小程序落地页->打开这个落地页即可参与协同合作
显然,在某些严谨的协助交互里,这种方式太过于随意,只要有人把链接泄露了,那么就会有意料之外的协同者来编辑这个事件,于是聪明的程序员会把设计思路改成这样:
新建一个事件(具备了一个唯一id,并指定具备权限的用户白名单)->传播一个带有这个id的小程序落地页->打开这个落地页并发现自己在权限白名单里即可参与协同合作
这样就比较严谨了,然而这个思路有个问题:需要事件发起人制定权限白名单,而在小程序里,如果发起一个协同合作事件到某个微信群里,其实事件发起者一般是想这个微信群里的所有成员都是具备协同权限的。
小程序的这个新能力的出现,就是弥补这个不足的,通过这个能力,能实现两个效果:1.群ID会以密文的方式传输,这样能保证除了特定群外,别的地方不可能会出现同样的小程序落地页,保证了事件不可外传;2.巧妙的共用了群权限,使得只要群员在群里,默认就具备了协同编辑的权限,这样就不需要事件发起者去定义某个事件的协同者白名单了。
确实,这就方便了。
其实这个能力就是一个微信群和小程序巧妙地共享权限的方式,把“发小程序到微信群”这一交互变成“发小程序到微信群,并把该微信群的所有成员加到小程序的协同这白名单里”。
牛吗?
虽然有些场景下,这能力挺鸡肋的(读者可自己发散一下思维想一下),但我觉得还挺牛的。