解读小程序敏感数据获取方式以及解密机制
话说，小程序内存在一种敏感数据的加解密机制，这个机制在不同开发接口/组件下有通用的解密方式，然而却具备不尽一样的交互机制，看不懂？没事，先接着往下看。
首先要明确一下什么是敏感数据，小程序内一般把头像、昵称、手机号、群名称、群id、微信运动等信息定义为敏感信息，接下来一一罗列所有敏感数据的获取方式：
一，获取用户头像/昵称数据
众所周知，如Nodes小程序一样，在小程序内要获取用户的头像/昵称数据时，需要经历一个授权阶段，很多人只知道“要授权”这个事情，而这个“授权”前后发生的事情可能不大了解。
事实上，要做到获取用户头像和昵称，要经历几个步骤（所有小程序都可以做到）：
- 登录（所谓的静默登录，为了获取登录态，需跟服务器进行交互）
- 用户资料授权（弹出授权确认框）
- 小程序会得到一些加密数据（头像、昵称）
- 客户端的小程序会把加密数据抛给服务器，服务器根据当前会话的key值来解密，并返回到客户端的小程序
思考：
这个授权机制其实迭代了好几次，也引发了不少运营事故，后来审核机制也对其做了限制，前阵子审核规范变更：小程序首次进入时不能直接弹出授权确认框，不然审核不通过。现在推荐的做法是在页面加一个“登录”之类的按钮来激发授权确认页面的展示。
二.群id和群昵称的获取
比获取用户资料复杂点，因为要涉及到小程序之间的交互，而且需要借助标签组件来展示数据，具体为以下步骤（所有小程序都能做到）：
- 转发主动方定义转发需要带上shareTicket参数
- 转发接收方进行静默登录
- 转发接收方获取shareTicket并初步获取加密数据（主要是群id）
- 转发接收方小程序把加密数据抛给服务器，服务器根据当前会话的key值来解密，并返回到客户端的小程序
思考：
值得关注的是，群信息一开始获取的机制中并没有引进“标签open-data”的方式，一开始群名称是直接返回供开发者使用的，后来因为市场反映“群名称直接开发会诱导出一些隐私暴露”的问题，但“直接砍掉群昵称”又会让群应用的产品形态变得局限，于是乎微信开发团队想了这么一个折中方案，花叔觉得挺6的。
对了，open-data这个标签目前貌似只有群信息获取的时候用到，这里留了个悬念，到底后面还会有那些open-data数据出现了，大家期待一下吧。
三.手机号的获取
手机号可算是高度敏感数据，它有权限限制，必须是认证过的企业主体的小程序才能获取。
它在小程序中的获取方式也是非常独特的，是“button组件+回调事件”的调用方式，具体步骤如下（只有认证的企业小程序能做到）：
- 登录（所谓的静默登录，为了获取登录态，需跟服务器进行交互）
- 在页面内定义一个open-type 的值设置为 getPhoneNumber的Button标签，并定义回调方法
- 用户主动点击上述Button标签
- 回调方法返回加密数据
- 客户端的小程序会把加密数据抛给服务器，服务器根据当前会话的key值来解密，并返回到客户端的小程序
思考：
值得关注的是，这是目前唯一一个“个人开发者小程序”以及“未认证企业小程序”没法获取的敏感数据，这是开了“数据权限控制”的头，相信未来可能会有更敏感的数据开放。
三.微信运动数据的获取
微信运动数据的获取跟“用户资料的获取”方式有点像，也需要弹出授权确认框以供用户主动接受或者拒绝。这个数据的获取主要依据以下步骤（所有小程序均可获取）：
- 登录（所谓的静默登录，为了获取登录态，需跟服务器进行交互）
- 调用wx.getWeRunData方法（弹出授权确认框）
- 用户授权后，小程序会得到一些加密数据（30天的运动数据，加密的）
- 客户端的小程序会把加密数据抛给服务器，服务器根据当前会话的key值来解密，并返回到客户端的小程序
思考：
这个就没啥要思考的了，花叔只想说，微信自己做的运动应用所用的接口跟对外的接口可不大一样哦，具体哪里不一样，这里就不分析了，有兴趣的同学可以私下探讨一下。
最后，大家应该注意到了，我在所有敏感数据获取步骤中都标红了第四步，因为这一步是数据解密的共用步骤，小程序所有敏感数据的解密基本都用这种方式。
关于通用解密：
花叔之所以说小程序更适合全栈开发者玩，就是因为它存在这种前后端互相配合的加解密机制，数据加密在前端，而解密这个步骤却是要控制在服务器，这个步骤主要分两步：
- 数据签名校验（利用小程序登录态来校验）
- 数据解密（用的是对称解密方法，官方有各种语言的示例代码）
过程有点复杂，说白了就是让提供小程序合法的登录态以及小程序的appid等信息，结合加密数据的密文，就可以解密成真实数据，具体技术细节可参考这里。
注.因为是个通用的数据解密方式，建议所有小程序开发者都了解一下。
讲完...