<dl id="3wz6h"></dl><li id="3wz6h"></li>

      1. <dl id="3wz6h"></dl>

      2. <dl id="3wz6h"><ins id="3wz6h"></ins></dl>

            <dl id="3wz6h"></dl>

            <dl id="3wz6h"><ins id="3wz6h"></ins></dl>
            1. 
              
              <output id="3wz6h"><ins id="3wz6h"><nobr id="3wz6h"></nobr></ins></output>

              <li id="3wz6h"><ins id="3wz6h"></ins></li>
              
              

            2. <output id="3wz6h"><ins id="3wz6h"><nobr id="3wz6h"></nobr></ins></output>
              首頁»數據庫»淺談數據庫用戶表結構設計,第三方登錄

              淺談數據庫用戶表結構設計,第三方登錄

              來源:nuanxin 發布時間:2017-09-28 閱讀次數:

                說起用戶表,大概是每個應用/網站立項動工(碼農們)考慮的第一件事情。用戶表結構的設計,算是整個后臺架構的基石。如果基石不穩,待到后面需求跟進了發現不能應付,回過頭來反復修改用戶表,要大大小小作改動的地方也不少。與其如此,不妨設計用戶表之初就考慮可拓展性,爭取不需要太多額外代價的情況下一步到位。

                先前設計:

                id
                username
                password

                用戶名加上密碼,解決簡單需求,留個id作為其他表的外鍵。當然,那時候密碼還可能是明文存儲,好點的知道md5。

                后來呢,隨著業務需求的拓展,要加個用戶狀態 status 判斷用戶是否被封禁,注冊時間和注冊IP地址、上次登錄時間和IP地址備查(并衍生出登錄記錄表,用來判斷是否異地登錄等,在此不表),用戶角色/權限 role (又衍生出用戶角色權限關系,還是另文討論),業務也需要個人的個人信息如真實姓名、地址等也一股腦往上添加,現在形成了一個很完整的用戶關系表。

                id
                username
                password
                realname
                address
                …
                status
                role
                register_time
                register_ip
                login_time
                login_ip

                現在問題來了,進入Web2.0時代,微博開放了第三方網站登錄,用微博帳號就能登錄我們的網站,老板說,這個我們得要。加個微博用戶登錄表吧,當然,得和我們自己的用戶表關聯,這個微博用戶信息表如下:

                id 自增ID
                user_id 關聯本站用戶ID
                uid 微博唯一ID
                access_token
                access_expire

                這還不算完,QQ又開放用戶登錄了,一下子要接入好多家第三方登錄了,只能就著“微博用戶信息表”繼續加類型加判斷,如果是每個第三方登錄都新建一個表,肯定會瘋的。

                時代變了,進入了移動互聯網時代,怎么也得支持個手機號登錄吧?所以現在每家標配都是:用戶名/郵箱/手機號登錄,外加一系列微博、微信等第三方登錄。表結構如下:

                用戶表:

                id
                username
                email
                phone
                …

                用戶第三方登錄表:

                id
                user_id
                app_type
                app_user_id
                access_token
                …

                用戶在輸入框輸入用戶名/郵箱/手機號和密碼之后,后臺判斷是郵箱、手機號或是用戶名,再根據條件查詢是否為特定用戶。這個表結構能夠承載未來一段時間的業務需求了。如果說某天冒出了一個新的登錄方式,比如身份證號登錄,怎么辦?繼續在用戶表加字段?我覺得有更好的選擇。

                改進版:

                無論username+password,還是phone+password,都是一種用戶信息+密碼的驗證形式;再來理解第三方登錄,其實它也是用戶信息+密碼的形式,用戶信息即第三方系統中的ID(第三方登錄一定會給一個在他們系統中的唯一標識),密碼即access_token,只不過是一種有使用時效定期修改的密碼。所以我們把它抽象出了用戶基礎信息表加上用戶授權信息表的形式。

                用戶基礎信息表 users:

                id
                nickname
                avatar

                用戶授權信息表 user_auths:

                id
                user_id
                identity_type 登錄類型(手機號 郵箱 用戶名)或第三方應用名稱(微信 微博等)
                identifier 標識(手機號 郵箱 用戶名或第三方應用的唯一標識)
                credential 密碼憑證(站內的保存密碼,站外的不保存或保存token)

                這個系統最大的特色就是,用戶信息表不保存任何密碼,不保存任何登錄信息(如用戶名、手機號、郵箱),只留有昵稱、頭像等基礎信息。所有和授權相關(且基本前端展示無關的),都放在用戶信息授權表,用戶信息表和用戶授權表是一對多的關系。說起來太抽象,show you the code.

                users

                |id|nickname|avatar|
                |1|慕容雪村|http://…/avatar.jpg|
                |2|魔力鳥|http://…/avatar2.jpg|
                |3|科比|http://…/avatar3.jpg|

                user_auths

                |id|user_id|identity_type|identifier|credential|
                |1|1|email|[email protected]|password_hash(密碼)|
                |2|1|phone|13888888888|password_hash(密碼)|
                |3|1|weibo|微博UID|微博access_token|
                |4|2|username|moliniao|password_hash(密碼)|
                |5|3|weixin|微信UserName|微信token|

                說說具體處理,用戶發來郵箱/用戶名/手機號和密碼請求登錄的時候,依然是先判斷類型,以某用戶使用了手機號登錄為例,使用 SELECT * FROM user_auths WHERE type=’phone’ and identifier=’手機號’ 查找條目,如有,取出并判斷password_hash(密碼)是否和該條目的credential相符,相符則通過驗證,隨后通過user_id獲取用戶信息。

                如果使用第三方登錄,則只要判斷 SELECT * FROM user_auths WHERE type=’weixin’ and identifier=’微信UserName’ ,如果有記錄,則直接登錄成功,使用新的token更新原token。假設與微信服務器通信不被劫持的情況下無需判斷憑證問題。

                通過這個表結構設計,使許多原來糾結的問題瞬間解決,說說優點吧:

                一,站內登錄類型無限拓展,代碼改動小。如果真要支持身份證登錄了,只要少許幾處改動,無需修改表結構。

                二,第三方登錄類型可用工場模式批量拓展,新增第三方登錄類型的開發成本降到最低。

                三,原來條件下,應用需要驗證手機號是否已驗證和郵箱是否已驗證,需要相對應多一個字段如 phone_verified 和 email_verified,如今只要在user_auths表中增加一個統一的verified字段,每種登錄方式都可以直觀看到是否已驗證情況。基于信任第三方登錄的數據準確性,默認第三方登錄都是已驗證。如果用戶修改登錄手機號或登錄郵箱,也能清晰跟蹤每一步的完成度。

                四,可按需綁定任意數量的同類型登錄方式,即一個用戶可以綁定多個微信,可以有多個郵箱,可以有多個手機號,是不是很贊?當然你也可以限制一種登錄方式只有一條記錄。

                五,在user_auths添加相應的時間和IP地址,就可以更加完整地跟蹤用戶的使用習慣,比如,已經不使用微博登錄兩年多,已經綁定微信300天

                六,即使完全使用第三方帳號登錄,可在前端做到“無需注冊本站帳號”的效果。過去許多網站雖然支持第三方帳號登錄,但出于留存用戶等原因,第一次微博登錄回來,讓你再填寫一套他們網站的郵箱、密碼等信息,也就失去了微博登錄的最大意義。從技術上說,原有的結構導致除了在微博用戶表建立一個條目外,必須在用戶表建立一條對應的條目,而且一般情況下不能讓用戶表里的郵箱或者用戶名和密碼留空。用戶體驗好的,郵箱自動生成 微博[email protected] ,密碼則隨機生成。至于體驗不好的,只能說早知道還不如不用微博登錄呢!現在呢,我們的這個用戶表結構則完全沒有這樣的困擾,只要微博提供的昵稱和頭像地址就可以生成這個用戶,再關聯他的微博登錄記錄。而且我們的表結構意味著,用戶可以解除他的所有登錄方式,于是這個賬戶變徹底變成了沒法登錄的僵尸(解決辦法是在代碼里加一個限制,至少保留一條user_auths的記錄)。如果你非得得到用戶的郵箱,那么每次登錄的時候看到他不存在一條identify_type為email的記錄,則彈窗彈死他,讓他趕快填郵箱,否則啥都別干。

                七,提升了邏輯思維能力。抽象出事物本質是碼農必備職業素養,通過對用戶表結構的學習研究,提高了鄙人的各方面技能,從此寫代碼一路順風順水…

                八,如果你說郵箱和手機號就是用戶信息的組成部分,他們依然需要體現在users表中作為前端展示?沒問題,users表盡管拓展,users表里依然有email,phone,但他們僅僅作為“展示用途”,和昵稱、頭像、或者性別這些屬性沒有本質區別。在用戶信息表與用戶授權登錄拆分后,用戶信息表可以隨時增加任意字段,加星座,加生日,都沒問題,只需要在前端展示時多幾個輸入框,錄入時多幾行代碼,與用戶登錄相關的問題做到最大程度解耦。

                有利必有弊,說說缺點:

                一,原先的用戶判斷由1次SQL變成2次SQL請求。

                二,用戶同時存在郵箱、用戶名、手機號等多種站內登錄方式時,改密碼時必須一起改,否則就變成了郵箱+新密碼,手機號+舊密碼訪問了,肯定是很詭異的情況。如果考慮到這一點,又要在user_auths表中新增一個表示站內登錄方式或第三方登錄方式的標識字段。

                三,代碼量增加了,有些情況下邏輯判斷增加了,難度增大了。

                舉個例子,無論用戶是否已登錄,無論用戶是否已注冊過,都是點擊同一鏈接前往微博第三方授權后返回,可能出現幾種情況:1,該微博在本站未注冊過,很好,直接給他注冊關聯并登錄;2,該微博已經在本站存在,當前用戶未登錄,直接登錄成功;3,該微博未在本站注冊,但當前用戶已經登錄并關聯的是另一個微博帳號,作何處理取決于是否允許綁定多個微博帳號;4,該微博未在本站注冊過,當前用戶已登錄,嘗試進行綁定操作;5,該微博已經注冊,用戶又已使用該帳號登錄,為何他重復綁定自己- -. 6,該微博已經在本站存在,但當前用戶已經登錄并關聯的是另一個微博帳號,作何處理?切換用戶或是報錯?(畫一個流程圖能更好描述這個問題)這個問題與采用的數據結構沒有關系,只是在做第三方帳號注冊登錄時遇到的各種情況,在此一并整理。

              QQ群:WEB開發者官方群(515171538),驗證消息:10000
              微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
              提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
              網友評論(共0條評論) 正在載入評論......
              理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
              登錄會員中心
              云南十一选往期