为了优化用户的使用体验,平台将回收“使用 wx.getUserInfo 接口直接弹出授权框”以及“使用 wx.authorize 接口直接申请提前授权用户信息”的能力,开发者需要使用组件方式唤起登录授权弹窗。
2018年10月10日后发布新版本的小程序,将无法在线上版本中使用接口直接弹出授权框。开发者可结合平台设计建议,提前做好兼容,合理使用微信登录能力。
能力调整背景
怎么合理使用微信登录能力
小程序登录流程设计建议
01
能力调整背景
推出微信登录能力的初衷是希望:当用户使用小程序时,可以便捷地使用微信身份登录小程序。但在实际使用场景中,我们发现:很多开发者在打开小程序时直接弹出授权框,如果用户点击拒绝授权,无法使用小程序。
在用户无法获知当前小程序服务内容的情况下,很多用户就会选择拒绝授权并离开当前小程序。所以“一进入小程序就要求用户授权”的做法打断了用户正常使用小程序的流程,同时也不利于小程序获取新用户。
所以平台调整登录接口,回收“使用 wx.getUserInfo 接口直接弹出授权框”以及“使用 wx.authorize 接口直接申请提前授权用户信息”的能力,并鼓励开发者参照以下指引合理改造小程序内的登录流程。
02
怎么合理使用微信登录能力
平台分别提供多种方式实现微信登录:
1. 调用wx.login接口,静默获取openid
适用场景:无需使用用户头像、昵称、Unionid信息
2. 使用 open-data (小程序)或者开放数据域(小游戏)的方式展示用户信息(无需用户授权)
适用场景:需要在前端“展示”用户头像、昵称信息,但不需要获取Unionid
3.使用button(小程序)或UserInfoButton(小游戏)组件,用户点击后弹窗请求用户授权
适用场景:需要获取用户头像、昵称、Unionid等基本信息
开发建议
第一步:获取openID
当用户访问小程序时,先通过wx.login,获取用户openID 。这时无需弹框授权,开发者拿到 openID 可以建立自身的帐号 ID。
第二步: 使用open-data方式或开放数据域方式展示头像昵称
如需要在前端展示用户头像、昵称信息, 使用open-data 方式或者开放数据域的方式展示用户信息
第三步:根据实际使用场景,使用组件,引导用户登录
在关键操作中,如必须获取用户头像、昵称、UnionID信息,可根据第一步获取的openID判断是新用户还是旧用户:
如果是旧用户,可以直接登录,也可定期使用wx.getUserInfo更新用户的信息;
如果是新用户,使用button(小程序)或UserInfoButton(小游戏)组件,在用户点击后弹窗请求获取用户基本信息。
03
小程序登录流程设计建议
a. 在必须用到登录信息的环节引导用户登录
在用户必须登录时才引导用户登录(如:购买前需要获取会员信息,用于同步积分数据),而不是用户一进入小程序就弹窗要求用户授权。如只需要在前端展示用户头像、昵称,无需要求用户授权,可直接展示。
b.清晰、准确地引导用户登录
在登录页面中,清晰、准确地告知用户当前操作是登录,说明获取登录信息的目的(如:用于同步会员积分数据等)
c. 不强制用户必须登录后才能使用小程序服务
提供游客模式,不强制用户必须登录后才能进入小程序。如要求必须授权头像昵称等信息才能继续使用小程序,会导致某些用户放弃使用该小程序。
不知道官方的奇葩脑回路是怎么想的,还是说一如既往的以为难开发者为己任?
在坑爹的openid机制下,unionid比起openid更是开发者所需要的,明显应该降低unionid的获取门槛
现在的open-data或者button获取机制只是徒增了开发者和用户的烦恼,我相信微信后台是能看到数据的,用户进到功能页面,9成的用户是会同意授权或者点击button的,在这种情况下,为什么要脱裤子放屁的方式给用户怎么麻烦?以增强用户体验之名,行降低用户体验之实,赞同openid和unionid同步返回给开发者的请点赞,让官方听听开发者的呼声。
首先,他们一开始搞出的openid机制就是完全错误的,他们又觉得自己是腾讯大厂,觉得承认错误并修改是很折面子的事情
其次,他们一直仗着自己店大欺客,根本就不在乎开发者是怎么想的,反正不管怎么样开发者都只能接受
核心问题是这些规则设计者太没经验了,之前看微信的api,从命名到使用方式都给人很强烈的新手程序员的赶脚。可能算是手快比较聪明的程序员,但是缺乏更高层面的设计能力,其实设计api给别人用是一个更难的事情。
难为人的主要原因,很可能是这些程序员就是没想明白。现在骗子打电话都直呼你姓名知道你信息的时代,微信那个劳什子的id有什么用吗,除了程序员为了标识用户之外。
用id标识用户其实没什么,只要id和用户是一一对应就行,但是微信脑残就脑残在一个用户在不同的公众号、小程序、各种登录里,这个所谓的openid是不一样的,这才是最没脑子的地方
到底会有多少用户会授权只有腾讯有真实数据,这个9成也是你一个开发为了自己方便臆想出来的。只有特别知名并且有信用的不会滥用用户数据的小程序我才会同意授权,其他的一律拒绝,哪怕不用。上来就授权也只有不考虑体验的人做的出来。如果全是垃圾小程序,微信坑定不会放任不管。
程序员何苦难为程序员!
用户不授权,对于产品后台来说就是没有“登录”。一个小程序的很多功能都是基于用户登录之后才正常运行。如果用户没有登录就进入到对应的业务逻辑页面,就会有各种异常的问题。你现在这样改,要求用户必须手动触发才能完成授权,就是要把本来在一进到小程序就可以完成用户的“登录”的逻辑,分散到各个业务逻辑页面去(当然或者也可以弄一个统一的页面专门做鉴权“登录”,但这样又会多一个页面跳转,影响用户体验)。导致的结果就是增加了小程序内页面逻辑的耦合度(耦合鉴权登录逻辑和业务逻辑),使得小程序各个页面杂糅了各种“登录”逻辑(因为你势必要处理统一授权和取消授权的这两个回调处理),从而使得页面内的业务逻辑不清晰,增加开发维护成本。
真是傻逼微信!无F**k说!
是的.没有登录,我们开发者做这个小程序何用?真的人人都是活雷锋不用吃饭么?不登录,怎么交互.没有交互.那来的收益...
所以啊,小程序永远都是“小”程序,没有大的发展空间了
基于工信部的一些要求,个人隐私问题上腾讯不想背上监管不力的锅,用户自己授权的话,这个就是用户自动提交个人信息,小程序太多了,运营队伍参差不齐,至于业务逻辑问题是程序员问题,数据收集是产品经理和运营的问题,这是小程序弯道超车的机会,碾压淘宝的机会,拭目以待,立帖为证!
微信:我做的我想改就改想删就删
大兄弟真的皮
我的微信我做主
同意你的说法啊,我现在就在为这个苦恼,我这后端怎么写呢?直接存一个open-id?那这个后端的登陆逻辑有和没有其实一个样,然后用户点一下按钮授权?拜托万一不点的话,没得玩而且还要单独给你留一个地方来放一个按钮,我简直是日了。综合起来看,我感觉最好的方式是在小程序打开的时候直接通过代码拿到用户信息,如果信息在后端没有那就调用接口让用户授权,很简单的逻辑。还要整一个什么open-data,请问我怎么获取这个open-data里面显示的数据呢?我是不是还要加一个hidden才能看上去和现有的页面没那么多的违和感。辣鸡,真是一个辣鸡程序员写的辣鸡项目。一点业务经验都没有。。。。。。。。。
我就要强制用户去授权,你要咋滴
业务需要必须要强制授权。。。
那就只能在登陆之前给个按钮强行让用户点击授权,mmp
我即使这样的,第一次进去就给他一个是否允许授权的按钮,不允许就不能用
大佬我想知道强制授权怎么写 不授权不让看其他页面那种
将getUserInfo改为按钮触发授权并没有什么意义,自己写一个授权弹框或者写多一个授权页面就又回到先授权后进小程序的局面了。还不如干脆在审核发布的时候限制死。
你做小程序吗,我需要请联系15343814081微信
聊妹,还能这么玩的。你也是牛逼
别这样,刚改的代码还以为你们又改了。。。
MB的,你这样对于那些都用Unionid来做用户标识的有什么作用??还不是一样的么。。。
openId就是个坑,为毛不直接把openId变成Unionid呢。不很多问题都解决了么。。甚至好多小程序都不需要按钮授权了。。。。
不同意授权 就是不让你用
哈哈哈,就是。
那还得做一个授权的页面不是,而且还是个index,真也是够了,这种辣鸡的业务逻辑设计,很简单的东西,非要用按钮去触发用户授权。。。。。,直接打开代码弹框不是更好吗?哎,脑子坏特了
微信为何要禁用自动获取用户信息弹窗,害我多写了多少代码,产品流程不会变的,很明显为难我们前端
那你有什么办法呢?
我觉得小程序的还算好的,有接口去打。我做公众号的,授权还要跳转到授权页面,授权完再打回来,再才是我自己的业务。流程就变成用户进入我的页面=>我跳转到授权页授权=>授权完再打回我的页面,这就得跳转三次页面了,尼玛的页面跳转好看吗?不要时间?每次人家测试或者运营就找我们前端说页面打开速度慢!尼玛,我能怎么办?
我们倒觉得用户不授权就不能用也没啥问题,你们倒是急的够呛,这可咋说呢,闲得蛋疼啊
本来就是,你用户不授权不就是相当于不登录吗?你微信怎么要让别人注册登录了再使用啊?你干嘛不弄个游客模式啊?
我就在后台搞了个游客模式的提示,有些用户不授权登录不到后台没办法