与这篇想比,前面几篇也不算是废话(这句话本身另谈),言归正传,我们来探讨一下小程序的用户授权和认证的事情。
通常情况下,我们会先说认证,再说授权,洋气一点就是Authentication & Authorization。但是,小程序场景下,我觉得还是先说Authorization,再聊Authentication比较符合开发顺序。
Authentication:解决“请证明你是你”的问题
Authorization:解决“你能做什么,不能做什么”的问题
微信小程序环境下,首先是微信用户对小程序本身的授权,比如:“我允许你访问我的个人信息”,其次才是小程序的后台服务器完成对用户的认证和小程序本身的业务授权。为了理清这个概念,我们得说一下“用户”身份问题。
用户
用户不是人(啪啪~~)...... 没错呀(呜呜~~)......
我们都知道,信息交互发生在客户端程序和服务器程序之间,对服务器而言,用户就是客户端程序,准确地说是用户的代理(用户是客户端,而客户端不是人,推导出上面的结论,刚才谁打我的?)。
授权
授权指的是微信用户对小程序的授权,允许或者不允许小程序访问某些信息(调用某些wx API)。特别是最近,小程序运行时开始限制旧的 机制,倾向于强制实施open-data规范,这个动作肯定大范围的影响了已发布的小程序,不然怎么会哭(mà)声一片。 的变化到底是什么呢?只能举栗子了。
老机制
新机制
差别很明显,代码不一样啦呀~~。实际上,新机制是强调显性的用户交互授权,伪代码中 这个逻辑值需要一次用户交互来置真,就是点击那个 “同意授权” 的对话框按钮。至于为什么这么做,只能自己去想象了,比如iOS要求这么做?
之前我也跟几个老同学聊过这个授权问题,有不少观点认为完全可以使用OAuth机制,姐也大部分支持这个观点,但也觉得其中有一点玄妙。
OAuth机制下,从授权方角度说,用户可以是“离线”状态的,比如你的Github账号以OAuth方式授权认证登录了X站,之后,你不需要保持在Github的登录状态,也可以以Github用户身份访问X站,而X站也可以使用你的Github AccessToken代理你,访问Github的某些API。小程序与此不同,简单理解大致是:要求“活体”授权,即非登录态的微信用户是不能去授权小程序的,因为你也可以做一个小程序Runtime来运行小程序,至于能干点什么,就需要脑洞啦。
认证
登录时序
能获取到的信息
通过 接口,可以获取 ,即登录凭证
通过 接口,可以获取 和加密的数据信息
换取openID/sessionKey所需要的信息
即登录凭证
注册小程序时分配
突然感到这部分内容很难写清楚,我想还是用一点简单的示例代码加注释来表达或许比较好。
注:代码中使用小程序原生API的callback写法,很难受,推荐使用第三方的wrapper,比如 github:weapp-next 来写就比较干净利索。
OK,小程序场景下的用户认证大致就是上面的示意代码所描述的这个过程了。这里再推荐一个node module,解决用户认证的服务器端逻辑,大家可以参考一下。
Github:xixilive/express-weapp-auth
晚安~!
领取专属 10元无门槛券
私享最新 技术干货