來源:www.dustyblog.cn
現在幾乎大部分的 App 都支持使用多個第三方賬號進行登錄,如:微信、QQ、微博等,我們把此稱為多賬號統一登陸,而這些賬號的表設計,流程設計至關重要,不然后續擴展性賊差,
本文不提供任何代碼實操,但是梳理一下博主根據我司賬號模塊的設計,提供思路,僅供參考,
一、 自建的登陸體系
1.1.1 手機號登陸注冊
該設計的思路是每個手機號對應一個用戶,手機號為必填項,
流程:
- 首先輸入手機號,然后發送到服務端,先判斷該手機號是否存在賬號,如果沒有,就會生成隨機驗證碼,將手機號和驗證碼系結到
Redis中,并設定一定的過期時間(過期時間一般是5分鐘,這就是我們一般手機驗證碼的有效期),最后將驗證碼通過短信發送給用戶, - 用戶接收到驗證碼后,在界面填寫驗證碼以及密碼等基礎資訊,然后將這些資料發送服務端,服務端收到后,先判斷在
Redis里面這個手機號對應的驗證碼是否一致,,失敗就回傳錯誤碼,成功就給用戶創建一個賬號和保存密碼, - 注冊成功后,用戶即可通過自己的
手機號+密碼進行登陸,
問題:
- 用戶體驗差,需要完成獲取驗證碼,填寫驗證碼/密碼/用戶名等諸多的資訊完成注冊,然后才能使用;
- 容易遺忘密碼,遺忘后,只能通過忘記密碼來重新設定密碼,
1.1.2 優化注冊登陸
該方案的思路是榷訓密碼的必填性,即無論用戶是否注冊過,可通過
手機號+驗證碼直接進行登陸(保留手機號+密碼登錄的方式),
流程:
- 輸入手機號,然后發送到服務端,服務端生成隨機驗證碼,將手機號和驗證碼系結到
Redis中,并設定一定的過期時間(過期時間一般是5分鐘,這就是我們一般手機驗證碼的有效期),最后將驗證碼通過短信發送給用戶, - 用戶接收到驗證碼后,在界面只需填寫收到的驗證碼,提交到服務端,服務端收到后,先判斷在
Redis里面這個手機號對應的驗證碼是否一致,失敗就回傳錯誤碼,成功就直接登錄,如果是老用戶,直接拉取用戶資訊;如果是新用戶,則提示他可以完善用戶資訊(不強制), - 用戶通過
手機號+驗證碼登錄后,也可選擇設定密碼,然后就可以通過手機號+密碼的方式登錄,即:密碼是非必填項,
用戶表設計:
| id | user_name | user_password | user_mobile | state | more |
|---|---|---|---|---|---|
| 用戶id | 用戶名 | 用戶密碼 | 手機號碼 | 賬號狀態 | 其他資訊 |
1.2 引入第三方賬戶方案
1.2.1 微博登錄
進入 Web2.0 時代 ,微博開放了第三方網站登錄, 產品說, 這個我們得要, 加個用微博帳號就能登錄我們的 App吧,而且得和我們自己的用戶表關聯,
流程:
- 客戶端呼叫微博登錄的界面,進行輸入用戶名、密碼,登錄成功后,會回傳
access_token,通過access_token調取API介面獲取用戶資訊, - 服務端通過用戶資訊在我們用戶表創建一個賬號,以后,該第三方賬號即可通過該微博賬號直接進行登陸,
微博用戶資訊表設計:
| id | user_id | uid | access_token |
|---|---|---|---|
| 主鍵id | 用戶id | 微博唯一id | 授權碼 |
1.2.2 噩夢來臨
緊接著, QQ又開放用戶登錄了, 微信開放用戶登錄了,網易開發用戶登錄了,,,,,,一下子要接入好多家第三方登錄了, 只能按照 “微博用戶資訊表” 新建一個表,重寫一套各個第三方登錄,
二、 優化賬號體系
2.1 原賬號體系分析
- 自建登陸體系:無論
手機號+密碼, 還是手機號+驗證碼, 都是一種用戶資訊+密碼的驗證形式; - 第三方登錄:也是
用戶資訊+密碼的形式, 用戶資訊即第三方系統中的ID(第三方系統中的唯一標識), 密碼即access_token, 只不過是一種有使用時效定期修改的密碼,
2.2 新的賬號體系
2.2.1 資料表設計
用戶基礎資訊表:
| id | nickname | avatar | more |
|---|---|---|---|
| 用戶id | 昵稱 | 頭像 | 其他資訊 |
用戶授權資訊表:
| id | user_id | identity_type | identifier | credential |
|---|---|---|---|---|
| 主鍵id | 用戶id | 登錄型別(手機號/郵箱) 或第三方應用名稱 (微信/微博等) | 手機號/郵箱/第三方的唯一標識 | 密碼憑證 (自建賬號的保存密碼, 第三方的保存 token) |
說明:
- 用戶表分為
用戶基礎資訊表+用戶授權資訊表; - 用戶資訊表不保存任何密碼, 不保存任何登錄資訊(如用戶名, 手機號, 郵箱), 只留有昵稱、頭像等基礎資訊; 所有和授權相關,都放在用戶資訊授權表, 用戶資訊表和用戶授權表是一對多的關系 ,
2.2.2 登錄流程
手機號+驗證碼
沿用之前的方案,
郵箱/手機號+密碼:
用戶填寫 郵箱/手機號+密碼; 請求登錄的時候, 先判斷型別, 如手機號登錄為例:
使用 type='phone' 結合 identifier='手機號' 查找, 如有, 取出并判斷 password_hash(密碼)是否和該條目的 credential 相符, 相符則通過驗證, 隨后通過 user_id 獲取用戶資訊;
- 第三方登錄, 如微信登錄:
查詢 type='weixin' 結合 identifier='微信 openId', 如果有記錄, 則直接登錄成功, 并更新 token; 假設與微信服務器通信不被劫持的情況下無需判斷憑證問題,
2.2.3 優缺點
優點:
- 登錄型別無限擴展, 新增登錄型別的開發成本顯著降低;
- 原來條件下, 應用需要驗證手機號是否已驗證和郵箱是否已驗證, 需要相對應多一個欄位如
phone_verified和email_verified, 如今只要在用戶授權資訊表表中增加一個統一的verified欄位, 每種登錄方式都可以直觀看到是否已驗證情況; - 在
用戶授權資訊表添加相應的時間和IP地址, 就可以更加完整地跟蹤用戶的使用習慣, 比如:已經不使用微博登錄兩年多, 已經系結微信 300天; - 如果你說郵箱和手機號就是用戶資訊的組成部分, users 表盡管拓展, users 表里依然有email , phone , 但他們僅僅作為“展示用途”,和昵稱,頭像或者性別這些屬性沒有本質區別;
- 可按需系結任意數量的同型別登錄方式, 即一個用戶可以系結多個微信, 可以有多個郵箱, 可以有多個手機號,當然你也可以限制一種登錄方式只有一條記錄;
缺點 :
-
用戶同時存在郵箱、用戶名、手機號等多種站內登錄方式時, 改密碼時必須一起改, 否則就變成了
郵箱+新密碼,手機號+舊密碼都可以登錄, 肯定是很詭異的情況; -
代碼量增加了, 有些情況下邏輯判斷增加了, 難度增大了; 舉個例子, 無論用戶是否已登錄, 無論用戶是否已注冊過, 都是點擊同一鏈接前往微博第三方授權后回傳, 可能出現幾種情況:
該微博在本站未注冊過, 很好, 直接給他注冊關聯并登錄;
該微博已經在本站存在, 當前用戶未登錄, 直接登錄成功;
該微博未在本站注冊, 但當前用戶已經登錄并關聯的是另一個微博帳號, 作何處理取決于是否允許系結多個微博帳號;
該微博未在本站注冊過, 當前用戶已登錄, 嘗試進行系結操作;
該微博已經注冊, 用戶又已使用該帳號登錄, 為何他重復系結自己;
該微博已經在本站存在, 但當前用戶已經登錄并關聯的是另一個微博帳號, 作何處理?
三、 一鍵登陸
3.1 背景
回顧一下 手機號+驗證碼 的登錄方式:
- 輸入手機號、等待驗證碼短信、輸入驗證碼、點擊登錄,整個流程走完可能需要 20 秒以上,操作也比較繁瑣;
- 它是依賴短信網路的,因為如果收不到短信,也就登錄不了了,
- 從安全角度考慮,還存在驗證碼泄漏的風險,如果有人知道了你的手機號,并且竊取到了驗證碼,那他也能登錄你的賬號了,
但回過頭來想一下,為什么我們需要驗證碼?驗證碼的作用就是確定這個手機號是你的,那除了使用短信,是否還有別的方式對手機號進行認證?
- 如果能獲取到當前使用的手機號,就能對用戶輸入的號碼進行驗證了,但出于安全考慮,客戶端是無法直接獲取到手機號的,運營商則可以通過
SIM卡資料查詢到, - 現在運營商已經開放了相關的能力,現在我們可以在用戶輸入手機號后,通過呼叫運營商的介面,判斷用戶輸入的手機號是否和本地號碼一致,這樣一來,用戶就省去了等待驗證碼短信、輸入驗證碼的程序,也不受短信網路的限制,簡化了登錄流程,
- 但再進一步想,如果運營商可以把當前的號碼直接回傳給我們,而不只是用于驗證,那用戶連手機號都不需要填了,
這就是該部分的主角:一鍵登錄 ,
3.2 本機號碼認證
獲取到當前手機使用的手機卡號,直接使用這個號碼進行登錄,這就是一鍵登錄,
這種登錄方式的好處是顯而易見的,它可以更方便、快捷地完成注冊、登錄流程,將原本可能需要 20 秒的流程,縮短到了 2 秒左右,很大程度上提升了登錄的用戶體驗,
主要步驟如下:
- SDK 初始化:呼叫 SDK 的初始化方法,傳入專案在平臺上的 AppKey 和 AppSecret,
- 喚起授權頁:呼叫 SDK 喚起授權介面,SDK 會先向運營商發起獲取手機號驗碼的請求,請求成功后跳轉到授權頁,授權頁會顯示手機號掩碼以及運營商協議給用戶確認,
- 同意授權并登錄:用戶同意相關協議,點擊授權頁面的登錄按鈕,SDK 會請求本次取號的 token,請求成功后將 token 回傳給客戶端,
- 取號:將獲取到的 token 發送到我們自己的服務器,由服務器攜帶 token 呼叫運營商一鍵登錄的介面,呼叫成功就回傳手機號碼了,服務器用手機號進行登錄或注冊操作,回傳操作結果給客戶端,完成一鍵登錄,
四、小結
博主看來,沒有最好的方案,選擇適用當前系統的設計即可,不要深究孰優孰劣,鞋合不合腳,只有腳知道,
近期熱文推薦:
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.別在再滿屏的 if/ else 了,試試策略模式,真香!!
3.臥槽!Java 中的 xx ≠ null 是什么新語法?
4.Spring Boot 2.5 重磅發布,黑暗模式太炸了!
5.《Java開發手冊(嵩山版)》最新發布,速速下載!
覺得不錯,別忘了隨手點贊+轉發哦!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/348177.html
標籤:其他
