(4)获取用户信息

背景

我们发现大部分小程序都会使用 wx.getUserInfo 接口,来获取用户信息。原本设计这个接口时,我们希望开发者在真正需要用户信息的情况下才去调取这个接口,但很多开发者会直接调用这个接口,导致用户在使用小程序的时候产生困扰,归结起来有几点:

  • 开发者在小程序首页直接调用 wx.getUserInfo 进行授权,弹框获取用户信息,会使得一部分用户点击“拒绝”按钮。

  • 在开发者没有处理用户拒绝弹框的情况下,用户必须授权头像昵称等信息才能继续使用小程序,会导致某些用户放弃使用该小程序。

  • 用户没有很好的方式重新授权,尽管我们增加了设置页面,可以让用户选择重新授权,但很多用户并不知道可以这么操作。

此外,我们发现开发者默认将 wx.login wx.getUserInfo 绑定使用,这个是由于我们一开始的设计缺陷和实例代码导致的(wx.getUserInfo 必须通过 wx.login 在后台生成 session_key后才能调用)。同时,我们收到开发者的反馈,希望用户进入小程序首页便能获取到用户的 unionId,以便识别到用户是否以前关注了同主体公众号或使用过同主体的App 。

为了解决以上问题,针对获取用户信息我们更新了三个能力:

1.使用组件来获取用户信息

2.若用户满足一定条件,则可以wx.login 获取到的code直接换到unionId

3.wx.getUserInfo 不需要依赖 wx.login 就能调用得到数据

获取用户信息组件介绍

组件变化:

  • open-type 属性增加 getUserInfo :用户点击时候会 bindgetuserinfo 事件。

  • 新增事件 bindgetuserinfo :当 open-type getUserInfo 时,用户点击会触发。可以从事件返回参数的 detail 字段中获取到和 wx.getUserInfo 返回参数相同的数据。

示例:

<button open-type="getUserInfo" bindgetuserinfo="userInfoHandler"> Click me button>

wx.getUserInfo 不同之处在于:

1.API wx.getUserInfo 只会弹一次框,用户拒绝授权之后,再次调用将不会弹框;

2.组件 由于是用户主动触发,不受弹框次数限制,只要用户没有授权,都会再次弹框。


通过获取用户信息的组件,就可以解决用户再次授权的问题。

直接获取unionId

开发者申请 userinfo 授权主要为了获取 unionid,我们鼓励开发者在不骚扰用户的情况下合理获得unionid,而仅在必要时才向用户弹窗申请使用昵称头像。为此,凡使用“获取用户信息组件”获取用户昵称头像的小程序,在满足以下全部条件时,将可以静默获得 unionid

1.在微信开放平台下存在同主体的App、公众号、小程序。

2.用户关注了某个相同主体公众号,或曾经在某个相同主体App、公众号上进行过微信登录授权。


这样可让其他同主体的App、公众号、小程序的开发者快速获得已有用户的数据

不依赖登录的用户信息获取

某些工具类的轻量小程序不需要登录行为,但是也想获取用户信息,那么就可以在 wx.getUserInfo 的时候加一个参数 withCredentials: false 直接获取到用户信息,可以少一次网络请求。

这样可以在不给用户弹窗授权的情况下直接展示用户的信息

最佳实践

1.调用 wx.login 获取 code,然后从微信后端换取到 session_key,用于解密 getUserInfo返回的敏感数据。

2.使用 wx.getSetting 获取用户的授权情况
 1) 如果用户已经授权,直接调用 API wx.getUserInfo 获取用户最新的信息;
 2) 用户未授权,在界面中显示一个按钮提示用户登入,当用户点击并授权后就获取到用户的最新信息。

3.获取到用户数据后可以进行展示或者发送给自己的后端。


One More Thing

除了获取用户方案介绍之外,再聊一聊很多初次接触微信小程序的开发者所不容易理解的一些概念:

1.关于OpenId和UnionId

OpenId 是一个用户对于一个小程序/公众号的标识,开发者可以通过这个标识识别出用户。

UnionId 是一个用户对于同主体微信小程序/公众号/APP的标识,开发者需要在微信开放平台下绑定相同账号的主体。开发者可通过UnionId,实现多个小程序、公众号、甚至APP 之间的数据互通了。

同一个用户的这两个 ID 对于同一个小程序来说是永久不变的,就算用户删了小程序,下次用户进入小程序,开发者依旧可以通过后台的记录标识出来。

2.关于 getUserInfo 和 login

很多开发者会把 login getUserInfo 捆绑调用当成登录使用,其实 login 已经可以完成登录,getUserInfo 只是获取额外的用户信息。

login 获取到 code 后,会发送到开发者后端,开发者后端通过接口去微信后端换取到 openidsessionKey(现在会将 unionid 也一并返回)后,把自定义登录态 3rd_session返回给前端,就已经完成登录行为了。而 login 行为是静默,不必授权的,用户不会察觉。

getUserInfo 只是为了提供更优质的服务而存在,比如展示头像昵称,判断性别,开发者可通过 unionId 和其他公众号上已有的用户画像结合来提供历史数据。因此开发者不必在用户刚刚进入小程序的时候就强制要求授权。

可以在官方的文档中看到 login 的最佳实践:



Q & A

Q1: 为什么 login 的时候不直接返回 openid,而是要用这么复杂的方式来经过后台好几层处理之后才能拿到?

A: 为了防止坏人在网络链路上做手脚,所以小程序端请求开发者服务器的的请求都需要二次验证才是可信的。因为我们采取了小程序端只给 code ,由服务器端拿着 code AppSecrect 去微信服务器请求的方式,才会给到开发者对应的openId 和用于加解密的 session_key。

Q2: 既然用户的openId 是永远不变的,那么开发者可以使用openId 作为用户的登录态么?

A: 行,这是非常危险的行为。因为 openId 是不变的,如果有坏人拿着别人的 openId 来进行请求,那么就会出现冒充的情况。所以我们建议开发者可以自己在后台生成一个拥有有效期的 第三方session 来做登录态,用户每隔一段时间都需要进行更新以保障数据的安全性。

Q3: 是不是用户每次打开小程序都需要重新login

A: 不必,可以将登录态存入storage中,用户再次登录就可以拿storage 里的登录态做正常的业务请求,只有当登录态过期了之后才需要重新login 。这样子做一则可以减少用户等待时间,二则可以减少网络带宽。

目前微信的session_key 有效期是三天,所以建议开发者设置的登录态有效期要小于这个值。

最后一次编辑于  08-17  (未经腾讯允许,不得转载)
收藏 0评论 62
  • livelive

    呵呵,刚发出来就立马审核不通过,你们有这么怕被吐槽,被反馈吗?


    赞同 14没有帮助
    8评论
    复制
    04-16
    • LttLtt
      你好,您的评论未通过审核是因命中了关键词,并非内容问题,这里还请不要误会。
      赞同 0没有帮助回复复制05-14
    • livelive
      请问命中了哪个关键词? 通篇看下来,没感觉哪个词是敏感词。
      赞同 0没有帮助回复复制05-15
    • BenzBenz
      刚刚测试了,关键词是:被cao(作)
      赞同 2没有帮助回复复制05-16
    • 展示更多
    评论
  • The.YoungThe.Young

    1)我的小程序主体上没有其他任何公众号和小程序;

    2)我的小程序没有首页,加个授权按钮势必体验很差;

    3)我今天只是在测试其他功能,顺手把授权清除了,直接导致我原本该一会儿就写完的东西写不下去了;

    4)花了一个多小时查资料看文档,才搞明白怎么回事,发现没有我要的结果;

    5)特别特别特别特别特别特别特别...伤心

    赞同 11没有帮助
    0评论
    复制
    05-11
  • 昊天 Haotian昊天 Haotian

    以后所有小程序都会有一个“登录”页面了, 这绝对不是你们想要的

    赞同 8没有帮助
    0评论
    复制
    04-20
  • 小黄人小黄人

    点了button后,弹出一个框,又要点一次允许,有没用考虑到用户的体验?差评

    赞同 7没有帮助
    0评论
    复制
    04-27
  • coder2017coder2017

    底层api啊,违反开闭原则,程序员伤不起。

    赞同 6没有帮助
    0评论
    复制
    05-02
  • livelive

    基础库版本,为了迎合一小部分只会用字符串对比的“开发者”,搞出 1.9.9 1.9.90 1.9.91 这种怪异的版本号。

    最底层的API,范围为了所谓的“用户体验”,强制将灵活的API调用限制为UI上的点击操作,还不提供全覆盖的场景升级说明。

    这就是微信的“平台”?

    赞同 5没有帮助
    0评论
    复制
    05-15
  • 润建通信润建通信

    看看谷歌做的动态权限,再看看这里~呵呵 这种控件做法耦合性不考虑了?

    赞同 5没有帮助
    1评论
    复制
    04-25
    评论
  • ..

    别急啊 接下来改的就可能是网络请求的api了 所有程序全部下架 重新修改审核也说不定呢

    赞同 3没有帮助
    0评论
    复制
    05-24
  • AaronAaron

    这个设计最愚蠢的地方在于,小程序要不要弹窗,弹窗频率,这个是小程序开发者决定的,不是平台开发者决定的。。。getUserInfo废弃了,默认不弹授权的窗口了,但只要有需要,小程序开发者不会弹自己开发的模态窗来提醒用户授权么。。。。

    赞同 3没有帮助
    0评论
    复制
    05-17
  • AI insight VictorAI insight Victor

    我认为,不应该通过关闭一个“能力”来达到优化用户体验,而是应该增加一个功能来提升用户体验。我们之前针对用户拒绝已经进行了重复的设计和考虑(我们会等待必要的时候,重新提醒用户),而现在由于小程序api的“善意升级”,使得我们必须全部推翻。


    我们强烈控诉这样的改变!因为未来我们所有的代码都是带着这样的“很有可能需要重构”的危险。也就是未来我们这样精心做设计的公司,反倒不如那些躺着等微信升级的公司。我们的优势和努力反倒成为负担,我们的努力反倒带来危险。


    我们认为任何时候,当部分开发者做的不够好时,应该通过“开放新能力”以及“加强审核”来改善开发体验和客户体验,而不是通过关闭一个能力,迫使过去认真开发的开发者重构代码来达到目标。

    赞同 3没有帮助
    0评论
    复制
    05-14