原文鏈接:https://www.cnblogs.com/kenshinobiy/p/9118024.html
=========================================
背景
小程序一個比較重要的能力就是獲取用戶信息,也就是使用 wx.getUserInfo
接口。我們發現幾乎所有的小程序都會調用這個接口。雖然我們在設計文檔上有提出最好的設計是在真正要用戶信息的情況下才去獲取用戶信息,不過很多開發者並沒有按照我們的期望去做,導致用戶在使用的時候有很多困擾。
歸結起來有幾點:
-
開發者在首頁直接調用
wx.getUserInfo
進行授權,彈框有會使得一部分用戶放棄小程序的使用。 -
開發者沒有處理用戶拒絕彈框的情況,有部分小程序強制要求用戶授權頭像暱稱等信息才能繼續使用小程序。
-
用戶沒有很好的方式重新授權,雖然在前幾個版本我們增加了
設置
頁面可以讓用戶選擇重新授權,但是操作還是不夠便捷。 -
開發者希望進到首頁就獲取到用戶的
unionId
,以便和之前已經關注了公衆號的用戶畫像關聯起來。 -
開發者默認將
wx.login
和wx.getUserInfo
綁定使用,這個是由於我們一開始的設計缺陷和實例代碼導致:getUserInfo
必須通過wx.login
在後臺生成session_key
後才能調用。
爲了解決以上幾點,我們更新了三個能力:
-
使用組件來獲取用戶信息,用戶拒絕授權後也可以重新彈窗再次授權
-
若用戶滿足一定條件(下文有詳細介紹),則可以用
wx.login
獲取到的code直接換到unionId
-
wx.getUserInfo
不依賴wx.login
就能調用得到數據。
獲取用戶信息組件介紹
組件變化:
-
open-type
屬性增加getUserInfo
:用戶點擊時候會觸發bindgetuserinfo
事件。 -
新增事件
bindgetuserinfo
:當open-type
爲getUserInfo
時,用戶點擊會觸發。可以從事件返回參數的detail
字段中獲取到和wx.getUserInfo
返回參數相同的數據。
示例:
|
和 wx.getUserInfo
不同之處在於:
-
API
wx.getUserInfo
只會彈一次框,用戶拒絕授權之後,再次調用將不會彈框 -
組件 由於是用戶主動觸發,不受彈框次數限制,只要用戶沒有授權,都會再次彈框
直接獲取unionId
考慮很多場景下,業務方申請userinfo授權主要爲了獲取unionid。我們鼓勵開發者在不騷擾用戶的情況下合理獲得unionid,而僅在必要時才向用戶彈窗申請使用暱稱頭像。爲此,凡使用“獲取用戶信息組件”獲取用戶暱稱頭像的小程序,在滿足以下全部條件時,將可以靜默獲得unionid。
-
在微信開放平臺下存在同主體的App、公衆號、小程序。
-
用戶關注了某個相同主體公衆號,或曾經在某個相同主體App、公衆號上進行過微信登錄授權。
getUserInfo 和 login
很多開發者會把login和getUserInfo捆綁調用當成登錄使用,其實login已經可以完成登錄,可以建立賬號體系了,getUserInfo只是獲取額外的用戶信息。
在login獲取到code,然後發送到開發者後端,開發者後端再通過接口去微信後端換取到openid和sessionKey(並且現在會將unionid也一併返回)之後,然後把3rd_session返回給前端,就已經完成登錄行爲。而login行爲是靜默,不必授權的,不會對用戶造成騷擾。
getUserInfo只是爲了提供更優質的服務而存在,比如展示頭像暱稱,判斷性別,通過unionId和其他公衆號上已有的用戶畫像結合起來提供歷史數據。所以不必在剛剛進入小程序的時候就強制要求授權。
推薦使用方法
-
調用
wx.login
獲取code
,然後從微信後端換取到sessionKey
,用於解密getUserInfo
返回的敏感數據。 -
使用
wx.getSetting
獲取用戶的授權情況-
如果用戶已經授權,直接調用 API
wx.getUserInfo
獲取用戶最新的信息 -
用戶未授權,在界面中顯示一個按鈕提示用戶登入,當用戶點擊並授權後就獲取到用戶的最新信息。
-
-
獲取到用戶數據後可以進行展示或者發送給自己的後端。
文檔中的quickStart已經更新
特別注意
爲了給用戶提供更好的小程序環境,我們約定在一段時間後(具體時間會做通知),若還出現以下情況(包括但不限於),將無法通過審覈
-
初次打開小程序就彈框授權用戶信息
-
未處理用戶拒絕授權的情況
-
強制要求用戶授權
已經上線的小程序不會受到影響。
===================================================
FAQ
Q: 除了 UserInfo 呢,比如說位置信息 --- ’風の諾言 .
A: 其他授權信息不像用戶信息那麼高頻繁,也基本是在使用時候才申請授權,所以沒有同 UserInfo 一起給出。我們會先看看 UserInfo 的使用情況再結合具體場景我們會給出相應的方案
Q: 後臺要維護用戶信息 --- Azleal
我們的小程序業務是功能都需要授權才能使用的(也就是必須拿到unionid獲取用戶信息) --- elemeNT
我在小程序與服務號的數據需要互通,通過unionId來確定用戶的唯一性,如果在用戶進入小程序後不強制他授權,單憑一個openid來存儲他的用戶數據,在用戶下次從服務號進入時。不就會產生重複數據嗎?就沒做到數據互通了 --- ﺭ並向你吐了趴口水ﺭ五年.
另外看到官方提到 要強制推行,我想說我們目前所有用戶是通過unionid註冊的。那麼這些用戶就不得不使用 openid重新登錄 、註冊一遍。更重要的是,之前他們的相關數據都會對應不上(因爲你們也不允許強制用戶登錄授權) --- 羊毛
現在這種方案,不能滿足我們的需求,我們的小程序,必須一進入就要獲取他的信息,然後加載他的數據; --- 韓文
A: 調用`wx.login`已經可以獲取到用戶的登錄態,已經可以做用戶賬號的管理。 UserInfo 中帶的 UnionId 是額外的信息,沒有它完全可以完成登錄
對於需要和開發平臺綁定的業務進行數據互通的情況,一個新用戶進來沒有互通數據的情況下也是可以體驗到所有業務,那麼對於沒有授權unionId的用戶,可以將其當成是新用戶,當真正授權unionId之後再做綁定完全是可以的
Q: 我需要確保用戶的唯一性,這樣就必須取unionID,否則用戶刪除了小程序,或者換了設備, 下次再進來這個小程序,該用什麼來區分是上次來過的用戶呢?? --- WEI+
A: 如果你本身沒有其他公衆號、App、小程序,那麼也就沒必要拿到unionid,因爲unionid是打通你在開放平臺下所有應用的標識
如果只有一個小程序,用 openid 足以, openid 是一個用戶對於一個小程序的標識,永遠不變
Q: wx.getUserInfo 是網絡請求,如果使用了 open-type = "getUserInfo",是否每次點擊都會調接口? --- SouthernBox
A: 是的,open-type="getUserInfo" 的作用以及內部實現基本和 wx.getUserInfo 一樣
區別是一個開發者主動(拒絕一次不再彈窗),一個是用戶主動(拒絕任意次都可以重新彈窗)
Q: 比如有一個創建按鈕,用戶點擊一次授權了,我已經獲取到用戶信息,再次點擊就沒必要再調用 getUserInfo 去網絡請求了。 --- SouthernBox
A: 可以參考文中 quickStart 的做法,如果已經授權了,那就可以把按鈕隱藏,之後的授權直接用API wx.getUserInfo 調用(因爲已經授權,所以也不會彈窗),用戶也不會再點了
Q: 小程序是不是必須要用微信自帶的授權纔可以登錄 ,能否不使用授權方式登錄,用自己系統的api接口數據實現?這個會不會涉及到審覈不過的問題??麻煩解答一下 謝謝了。 --- WEI+
A: 自己做登錄不會涉及到審覈問題。
不過不建議在沒有原有賬號體系的情況下讓用戶在小程序內註冊,過重的行爲會損失用戶。
Q: 在小程序中有一個"我的"頁面,這是屬於會員頁,如果用戶要進入這個頁面就必須授權。交互方式就是在用戶未授權情況下整個頁面只顯示一個授權獲取用戶信息的button 按鈕,這個需要用戶自己去觸發,算不算強制授權? --- ﺭ並向你吐了趴口水ﺭ五年.
A: 強制授權是說如果用戶如果不授權基本信息,連最基礎的瀏覽功能都不提供(當然這個也是要分具體的業務場景,不會限制得太死板)
可以有更好的交互,參考下主流App,在未登錄的時候點擊【我的】頁面,也不會直接要求登錄,而是展示了一定的頁面結構,同時給一個登錄按鈕(例如【攜程】【京東】等),之後再在這個頁面做操作的話可以彈一個登錄頁面或按鈕提示用戶登錄是完全可以的。
上述所說的登錄只是用戶感知上的登錄,從業務邏輯上用戶其實在 wx.login 的時候已經完成登錄了。
Q: 看了很多評論,有些人還是不知道爲什麼官方要這樣做,我作爲一個商家角度來說下。 --- Mr.J
1. 比如我們要做一些戶外推廣的二唯碼,用戶只看到了你的圖片宣傳單,掃描二唯碼一打開就提示“需要獲取你的個人信息,您是否允許”,你不要當自己是開發者當自己是一個正常人,看到這個提示我相信很多人的第一反應就是拒絕。如果第一步已經把你拒之門外,談何營銷?
2. 沒有小程序之前,我們在公衆號有很多用戶,都綁定了unionid,有小程序之後我們考慮怎麼讓用戶接受小程序,可以靜默登錄我覺得非常好,從公衆號過來的用戶可以直接就登錄了,沒有任何提示,完美的對接,這是一個很好的體驗。
A: 說得很好,我們的這些改造不僅是爲了開發者,同時也是爲了這個生態下的用戶考慮。希望開發者們也能站在用戶的角度去思考怎麼做一個產品。
Q: 我不明白爲什麼login 給多個unionid 爲什麼不行? unionid也不能算是個人信息吧,給多個unionid可以更方便開發者,而且很多情況下就不用調用getUserInfo了 --- candyTong
我們提個建議,能否直接開放unionid呢?這樣也許會有許多小程序不需要再彈窗了。既一定程度保障了用戶體驗,也照顧到了我們開發者的體驗。 --- 羊毛
A: 如果直接開放了unionid,就會出現這種情況:當你作爲一個用戶進入一個小程序,這個小程序並沒要求你授權就直接把你的頭像暱稱顯示出來(它之前把unionId對應的頭像暱稱都存了下來),但是這個小程序主體(open平臺主體和公衆平臺主體並不相同)相關的任何一個應用你從來沒用過,你會不會覺得很奇怪並且很不舒服,覺得自己在微信內的用戶信息沒有絲毫的保障?
Q: 那有推薦的比較好的例子麼?對於必須使用用戶頭像、暱稱這些信息的小程序而言 --- 亞里士朱德
A: 首先,沒有什麼邏輯是一定要使用用戶的頭像、暱稱才能work的。對於這個case,完全可以先用默認頭像、匿名暱稱先做替代,用戶點擊默認頭像後就可以彈出授權信息,非常的水到渠成。
Q: 之前看了這個帖子一直在思考,如果是一進去需要回去用戶的地理位置信息顯示到地圖上的呢?這樣算不算是一進去就彈窗授權獲取用戶信息? --- 吳俊績🤔
A: 地圖的情況和獲取用戶信息不同,我們目前還沒對地圖的授權請求有所調整。當前不受上述策略的影響
Q: 對於開發者而言,小程序與公衆號是同級的,只是不同的入口 但是這樣的設計,公衆號與小程序成了主從關係咯 --- log琥珀①
A: 並無什麼主從關係,只是多一個渠道讓開發者可以更方便的獲取到已經是該主體下用戶的unionId
轉自:https://developers.weixin.qq.com/blogdetail?action=get_post_info&lang=zh_CN&token=1642201843&docid=c45683ebfa39ce8fe71def0631fad26b