注冊和登錄幾乎是所有產(chǎn)品的必備功能之一,，本文作者以細節(jié)規(guī)則為例,，講解了注冊、登錄功能背后的設(shè)計原理,，一起來看一下吧,。

注冊和登錄功能幾乎是所有產(chǎn)品的必備功能之一。對于用戶,，注冊,、登錄后就可以生成唯一標(biāo)識用戶身份的信息，并基于此信息同步用戶行為數(shù)據(jù),。對于平臺或公司，用戶注冊時填寫的有效信息可以有利于后期的精細化運營,。

下面以細節(jié)規(guī)則為例講解注冊,、登錄功能背后的設(shè)計原理。

一,、校驗信息時的正則表達式

如圖6-1所示,，這是一款需要用戶提供手機號和驗證碼進行注冊、登錄的App,。在用戶輸入正確的手機號和驗證碼后,，App服務(wù)器會校驗該手機號是否已注冊，若用戶未注冊就點擊“登錄”按鈕,，App會先幫用戶完成注冊,，若用戶已注冊，則會成功登錄,。

再來對比兩種情況,。第一種情況，將手機斷網(wǎng)并設(shè)為飛行模式,。當(dāng)手機號碼輸入框中沒有任何內(nèi)容時,，發(fā)送驗證碼的按鈕處于置灰狀態(tài)且顯示“請輸入11位手機號碼”的提示文案。當(dāng)在手機號碼輸入框中輸入了符合正常手機號碼格式的手機號時,，發(fā)送驗證碼的按鈕處于可以點擊的狀態(tài)（顏色由灰變藍）,。

圖6-1 登錄頁面手機號碼校驗示意圖1

對照圖6-2看看第二種情況。在手機號碼輸入框內(nèi)輸入了12位數(shù)字時,，發(fā)送驗證碼的按鈕再次處于置灰狀態(tài),。將輸入的數(shù)字調(diào)整為11位，并將首位數(shù)字改為2,，即調(diào)整為不符合正常手機號碼格式的情況,，發(fā)送驗證碼的按鈕也處于置灰狀態(tài),。

圖6-2 登錄頁面手機號校驗示意圖2

總結(jié)一下上面兩種情況。在無網(wǎng)絡(luò)情況下,，App會對手機號碼進行是否符合格式要求的校驗,。

那么如何校驗?zāi)兀恳话憧梢酝ㄟ^正則表達式,。比如在上面的案例中,，只要是1開頭的11位數(shù)字就是符合要求的，可用正則表達式表示為 /^1[0-9]{10}$/,。

二,、怎么實現(xiàn)記住密碼功能

為了方便用戶下次登錄，常見做法就是在用戶第一次登錄時,，引導(dǎo)用戶勾選類似記住密碼的選項,，當(dāng)用戶下次打開App時就可以直接登錄App，如圖6-3所示,。

圖6-3 登錄時的記住密碼功能

但登錄時用戶長期無須輸入密碼也存在一定的安全風(fēng)險,，部分平臺在方便與安全之間做出了權(quán)衡，提供了多少天內(nèi)免登錄的選項,。超出限制時間后,，用戶再打開App時依然需要輸入密碼。

在如圖6-4所示的案例中,，登錄印象筆記網(wǎng)頁版時,，勾選了“30天內(nèi)記住我”復(fù)選框，這樣用戶30天內(nèi)均可自動登錄印象筆記網(wǎng)頁版,，超出時間后才需要重新手動登錄,。

圖6-4 登錄時的“30天內(nèi)記住我”功能

上述案例的核心技術(shù)原理分為兩個方面，一個方面是如何記住密碼,，另一個方面是如何設(shè)置賬號,、密碼的有效期。

賬號和密碼可以記錄在本地,。打開產(chǎn)品時,，便將預(yù)先保存在本地的賬號和密碼取出，與服務(wù)器進行校驗,。這里的“本地”,，對于Web產(chǎn)品來說就是在瀏覽器中，對于App來說則是在手機中,。

常見的技術(shù)解決方案有哪些呢,？

首先，是基于Cookie的方案。

Cookie是客戶端向服務(wù)器發(fā)起請求后,，服務(wù)器返回給客戶端的信息之一,，客戶端會將Cookie保存下來并在后續(xù)接口中帶上該信息，使服務(wù)器可以判斷是哪個客戶端發(fā)起的請求,。

在自動登錄場景下,，用戶首次登錄后，賬號和密碼會被記錄在Cookie中,，后續(xù)登錄時,，客戶端便從本地取出Cookie中的賬號和密碼發(fā)送給服務(wù)器驗證，通過后登錄成功,，省去了用戶手動重復(fù)輸入賬號和密碼的過程,。

在Web類型的產(chǎn)品中，則是利用localStorage來實現(xiàn)記住密碼功能的,。localStorage是HTML5標(biāo)準(zhǔn)中新加入的一種技術(shù),，該技術(shù)用于解決Cookie存儲空間比較小的問題。與每條Cookie僅4Kb的容量大小相比,，localStorage的容量大小一般會達到5Mb,，具體容量大小在不同的瀏覽器中會存在差異。并且,，保存在localStorage中的數(shù)據(jù)是永不過期的,，除非進行了主動清空操作,。

但把賬號和密碼信息保存在本地,，存在賬號密碼被泄露及偽造的風(fēng)險。所以,，基于Token的方案便應(yīng)運而生,。大致過程與基于Cookie的方案類似，只是Token中無須保存賬號和密碼信息,，從而提高了安全性,。

首先,，依然是借助Cookie方案,。在客戶端向服務(wù)器發(fā)起請求之后，服務(wù)器給客戶端返回Cookie時,，直接設(shè)置好過期時間,，一旦過期，客戶端的Cookie信息就會被清除,，后續(xù)登錄則需要重新驗證,。

另外，就是借助Token方案。Token類似于Cookie,，也可以設(shè)置過期時間,。設(shè)定過程如下：首次登錄時，客戶端將賬號和密碼發(fā)送給服務(wù)器,，服務(wù)器創(chuàng)建refresh token和token兩個參數(shù),，將它們綁定，并設(shè)置不同的過期時間（一般可將token參數(shù)的過期時間設(shè)定得更早）,，后續(xù)登錄只需帶著Token即可校驗,。Token過期了以后，客戶端就會向服務(wù)器重新申請Token,，此時會先比對之前的refresh token,，匹配后便生成新的token替換掉之前refresh token綁定的token，并將新的token返回給客戶端,，后續(xù)客戶端發(fā)送請求時,，帶上新的token即可，于是用戶的登錄狀態(tài)便是一直可用的,，直到token和refresh token參數(shù)都過期后,，用戶才需要重新輸入賬號和密碼,。

三,、單點登錄

公司的產(chǎn)品數(shù)量不多時，用戶注冊賬號登錄,，并結(jié)合記住密碼功能,，便可滿足用戶短期內(nèi)均無須再次輸入賬號和密碼的需求。

但公司產(chǎn)品數(shù)量增加后,，依然會讓用戶感受到注冊登錄過程的煩瑣,。比如，騰訊,、阿里這類大型公司旗下有眾多產(chǎn)品,，產(chǎn)品之間往往會產(chǎn)生關(guān)聯(lián)，如果用戶在使用其中某款產(chǎn)品時需要跳轉(zhuǎn)到其他產(chǎn)品進行登錄認證,，一定會感到十分不便,。對于產(chǎn)品設(shè)計者，也需要設(shè)計重復(fù)的登錄認證邏輯,。

解決這類問題的技術(shù)方案叫單點登錄,，英文全稱是Single Sign On，縮寫是SSO,。這里有一個誤區(qū),，因為很多產(chǎn)品經(jīng)理一直以為,，同一時間只允許一個賬號在一臺設(shè)備上登錄的需求就是單點登錄，但實際上單點登錄是指產(chǎn)品中存在多套不同的系統(tǒng),，并且這些系統(tǒng)之間彼此是可信任的,，只需讓用戶登錄一次，后續(xù)便可直接登錄產(chǎn)品中的任一系統(tǒng),。

目前市面上最主流的單點登錄方案實現(xiàn)思路,，要么是基于Cookie和Session自己搭建，要么是借助現(xiàn)成框架實現(xiàn),。

一般公司的不同產(chǎn)品均位于同一個根域名下,，但也不排除有些公司一條業(yè)務(wù)線或一個產(chǎn)品就占用一個單獨的域名。舉例說明,，如果公司服務(wù)器域名為example.com,，且存在兩個系統(tǒng)對應(yīng)的子域名為big.example.com及huge.example.com，在提供了登錄功能的情況下,，用戶如果要打開這兩個域名對應(yīng)的系統(tǒng)頁面,，是需要分別登錄的。那么怎樣才能讓用戶在登錄了其中一個系統(tǒng)后,，打開另一個域名對應(yīng)的系統(tǒng)時無須重復(fù)登錄呢,？

借助前面講解過的Cookie知識，如果用戶登錄其中一個系統(tǒng),，在客戶端本地記錄下用戶登錄的Cookie信息,，下次用戶依然在同一端打開另一個系統(tǒng)登錄，是不是可以將之前用戶本地保存的Cookie信息拿過來直接用呢,？遺憾的是,，Cookie的使用不支持跨域，即不能直接拿Cookie中關(guān)于big.example.com域名的賬號信息直接登錄huge.example.com,。那么,，如何解決這個問題呢,？好在設(shè)置Cookie時,，除了可以設(shè)置當(dāng)前域的信息，還可以設(shè)置對應(yīng)的頂級域名,，即example.com,，在子域中又可以訪問頂級域中的Cookie信息。

拿到登錄賬號信息還沒完,，還需要驗證賬號是否依然處于登錄狀態(tài),，此時就要借助Session來完成了。

用戶在某個子域名登錄后,，服務(wù)器可在數(shù)據(jù)庫中保存Session信息,，其中就記錄了登錄狀態(tài)。只要登錄狀態(tài)尚未結(jié)束，便可根據(jù)Cookie找到Session,，保持之前的登錄狀態(tài),。具體如何根據(jù)Cookie找到Session呢？例如,，用戶在子域名big.example.com登錄后,，保存的是cookie1并生成對應(yīng)的session1，然后在子域名huge.example.com登錄,，保存的是cookie2并生成對應(yīng)的session2,，兩個獨立的Session是無法知道彼此的登錄狀態(tài)的。為了解決這個問題,，就需要借助Session共享技術(shù),。簡單來講，就是可將第一個子域名對應(yīng)的系統(tǒng)與服務(wù)器會話時生成的Session共享給同一個根域名下的其他子域名使用,，這樣就可以解決有登錄的Cookie信息,，但沒法確定登錄狀態(tài)，從而實現(xiàn)用戶的免密登錄,。

上面的方案已經(jīng)能夠解決不同產(chǎn)品歸屬同一頂級域名下情況的登錄問題,，但如果各個業(yè)務(wù)線域名都是獨立的，那怎樣實現(xiàn)單點登錄呢,？下面介紹市面上比較成熟的開源解決方案CAS,。

在實現(xiàn)CAS這套方案時，除了需要提供正常的業(yè)務(wù)系統(tǒng),，還需要一個專門負責(zé)認證用戶的系統(tǒng),，用于存儲登錄用戶的標(biāo)識。用戶在登錄其他系統(tǒng)時,，借助已存儲的標(biāo)識進行驗證,，這時用戶無須再次登錄。在整套CAS方案中,，認證系統(tǒng)被稱為CAS Server,，業(yè)務(wù)系統(tǒng)被稱為CAS Client。

實現(xiàn)過程大致可以分為兩個環(huán)節(jié),，一是初次登錄,，二是后續(xù)登錄。

下面通過案例進行說明,。假定某個集團公司叫小風(fēng)科技集團,，旗下的子公司分別叫中風(fēng)科技發(fā)展有限公司和大風(fēng)科技發(fā)展有限公司。中風(fēng)科技發(fā)展有限公司主營業(yè)務(wù)是線上社交類電商,，大風(fēng)科技發(fā)展有限公司主營業(yè)務(wù)是線上醫(yī)療,。兩家公司原本獨立運營,，產(chǎn)品研發(fā)分離，域名也是獨立申請的,。因為戰(zhàn)略方向上的調(diào)整,，兩家子公司的業(yè)務(wù)需要產(chǎn)生關(guān)聯(lián)，需要進行產(chǎn)品整合,，整合任務(wù)之一就是實現(xiàn)系統(tǒng)的單點登錄,。

先說初次登錄。用戶在使用子公司中風(fēng)科技發(fā)展有限公司的產(chǎn)品時,，之前登錄時會直接請求服務(wù)器,，改造為CAS模式后，則會變成先去請求CAS Server,，若無法找到Cookie信息,，則判定為初次登錄，然后提示用戶輸入賬號和密碼進行登錄,。完成后,，CAS Server便將登錄信息（包括登錄狀態(tài)）一并寫入服務(wù)器Session中，并記錄下登錄的Cookie信息,。此外,，它還會在登錄成功后，生成一個叫作ST（Service Ticket）的內(nèi)容,，ST會在CAS Server和業(yè)務(wù)系統(tǒng)之間做來回的雙向驗證,，雙方確認無誤后，首次登錄就成功了,。

再說后續(xù)登錄,。用戶想要訪問其他業(yè)務(wù)系統(tǒng)時，也會先將登錄信息提交給CAS Server,，待找到匹配的Cookie和Session信息,，并經(jīng)歷ST的雙向驗證通過，就可以實現(xiàn)后續(xù)用戶登錄其他業(yè)務(wù)系統(tǒng)時,，無須再次輸入賬號和密碼便能直接登錄的需求,。

OAuth實際上是一種開放協(xié)議。通過這種協(xié)議,，可以讓第三方應(yīng)用獲取到用戶在某一個平臺存儲的與個人信息相關(guān)的資源,，并且在獲取這些信息時,，不需要用戶提供賬號和密碼,。

在講解怎么樣借助OAuth方案實現(xiàn)單點登錄前，先講講OAuth協(xié)議的授權(quán),。

如圖6-5所示,，登錄京東網(wǎng)頁版時,，選擇使用微信等第三方賬號授權(quán)登錄，會展示讓微信用戶授權(quán)的二維碼,，在用戶掃碼同意授權(quán)以后,，微信開放平臺便會驗證用戶身份是否正確，如果正確,，會生成一個臨時的憑證給用戶,，用戶再拿著這個臨時憑證去微信開放平臺換取access_token（注意這里的access_token是OAuth 2.0協(xié)議中客戶端訪問資源服務(wù)器時需要帶上的令牌，有了這個令牌說明用戶已經(jīng)同意授權(quán)了）,。到這一步后,，基本上就已經(jīng)完成了授權(quán)登錄的過程。當(dāng)然,，后面還需要通過從微信獲取到的用戶信息來生成會話,。

圖6-5 京東網(wǎng)頁版登錄功能

在整個交互流程上，OAuth協(xié)議中涉及4個不同的角色,，分別是resource owner（資源擁有者）,、resource server（資源服務(wù)器）、client（客戶端）,、authorization server（授權(quán)服務(wù)器）,，不同的角色會起到不同的作用。資源擁有者代表用戶信息歸屬于誰,，在上面的案例中資源擁有者就是微信用戶,。資源服務(wù)器是存儲授權(quán)后訪問網(wǎng)頁的用戶信息的服務(wù)器，比如微信服務(wù)器,?？蛻舳思窗l(fā)起訪問的客戶端。授權(quán)服務(wù)器則是專門用于處理認證授權(quán)的服務(wù)器,，在上面的案例中微信開放平臺提供的認證服務(wù)器便充當(dāng)了這個角色,。上面的角色還可以繼續(xù)簡化，但至少需要保留客戶端和授權(quán)服務(wù)器,。

四,、多終端設(shè)備的用戶互踢

同一時間只允許一個賬號在一臺設(shè)備上登錄，很多產(chǎn)品這樣做是為了避免出現(xiàn)賬號被他人使用但用戶無法察覺的情況,。針對這類需求,，由于終端的差異，因此存在著不同的實現(xiàn)方式,。

下面先來梳理場景,。既然是端對端的訪問過程，假定用戶小風(fēng)使用A賬號在某個瀏覽器或App中登錄,，此時向服務(wù)器發(fā)起請求,，服務(wù)器就會創(chuàng)建一個Session用于保持與客戶端之間的會話狀態(tài),。與此同時，服務(wù)器會基于客戶端傳來的一些參數(shù)（比如UUID,、MAC地址等設(shè)備唯一標(biāo)識）來生成Token,，并將該Token與賬號綁定，保存在服務(wù)器,。另一個用戶大風(fēng),，這時也使用同樣的賬號A在不同的設(shè)備中登錄，也同樣會向服務(wù)器發(fā)起請求,，服務(wù)器則會根據(jù)客戶端提交的賬號進行查詢,，發(fā)現(xiàn)Token已經(jīng)存在，說明該賬號還處于登錄狀態(tài),，但由于大風(fēng)也向服務(wù)器發(fā)起了請求,，所以為了確保大風(fēng)能正常登錄，便會生成一個新Token并將之前的Token信息刪除,。

在用戶登錄后,，服務(wù)器還需要通知前面登錄的用戶被擠出登錄的事實。

結(jié)合前面所學(xué)的網(wǎng)絡(luò)請求相關(guān)知識,，無論是移動端還是Web端,，在與服務(wù)器交互的過程中，均為客戶端發(fā)起請求,，服務(wù)器響應(yīng)并返回信息給客戶端,。采用這種方式意味著，雖然前面登錄的用戶明明已經(jīng)被后面登錄的用戶“擠”了下去,，但還是得通過某個特定的操作,，向服務(wù)器發(fā)起請求，服務(wù)器查詢到新用戶使用同一個賬號登錄,，才會為前面的用戶注銷登錄,。于是，就會出現(xiàn)在一段時間內(nèi),，存在兩個用戶同時登錄的狀態(tài),。

因此，服務(wù)器如果能主動向客戶端推送消息,，就可以解決上面的問題,，下面介紹兩類解決方案。

輪詢,，可以被理解為在客戶端,，通過定時任務(wù)，定時向服務(wù)器發(fā)起請求，服務(wù)器收到請求后根據(jù)請求的信息進行響應(yīng),。采用這種方式,，有利有弊,，優(yōu)點是技術(shù)實現(xiàn)方便,，缺點是會產(chǎn)生大量無效請求，加重網(wǎng)絡(luò)負載,，甚至還會造成服務(wù)器性能的浪費,。

為了減少不必要的請求，便出現(xiàn)了長輪詢,。長輪詢與輪詢的不同之處在于,，輪詢時服務(wù)器收到客戶端的請求后會立即響應(yīng)，長輪詢時服務(wù)器收到客戶端的請求后不立即響應(yīng),，而是會暫時保持發(fā)起請求后的連接狀態(tài),，直到服務(wù)器得到客戶端想要的結(jié)果后才通知客戶端，從而減少向服務(wù)器發(fā)起請求的次數(shù),。

無論是輪詢還是長輪詢,，都基于HTTP協(xié)議，該協(xié)議最大的缺點是無法做到服務(wù)器向客戶端主動推送消息,。為了克服這一缺點,，下面將引出WebSocket方案。

WebSocket也是一種網(wǎng)絡(luò)通信協(xié)議,，但WebSocket協(xié)議與HTTP協(xié)議不同,，其服務(wù)器與客戶端之間可以雙向互推消息。它最常見的應(yīng)用場景便是即時通信,、視頻網(wǎng)站彈幕,、在線協(xié)同文檔等。

WebSocket方案的實現(xiàn)原理大致如下：客戶端發(fā)起HTTP協(xié)議請求到服務(wù)器,，并在請求頭中附加Upgrade: WebSocket信息來表明將協(xié)議升級為WebSocket,，服務(wù)器收到請求后返回允許客戶端切換協(xié)議的響應(yīng)信息 switching，此時雙方便以WebSocket方式開啟了通信管道,，直到任意一方?jīng)Q定主動關(guān)閉,。

五、離線登錄是怎么一回事

離線登錄指沒有網(wǎng)絡(luò)或服務(wù)器出現(xiàn)故障時,，用戶依然可以正常登錄并使用產(chǎn)品,。比如，對于隨手記記賬產(chǎn)品,，用戶在注冊登錄后,，可記錄自己的消費情況，進而形成好的理財習(xí)慣,。為了兼顧用戶體驗及技術(shù)實現(xiàn),，一般會設(shè)計為在無網(wǎng)情況下,，用戶可以通過離線模式將數(shù)據(jù)記錄在本地，待網(wǎng)絡(luò)恢復(fù)后,，再將數(shù)據(jù)上傳至服務(wù)器,。

想要實現(xiàn)離線登錄，最好用戶曾經(jīng)采用聯(lián)網(wǎng)的方式登錄過產(chǎn)品,，確?？蛻舳吮镜乇４媪擞脩舻腃ookie信息，甚至還可以緩存一部分軟件使用過程中的數(shù)據(jù)（比如剛才的記賬信息）,，也就是通過本地數(shù)據(jù)持久化的方式進行實現(xiàn),，Cookie信息便是其中一種數(shù)據(jù)持久化方式。除此之外,，將賬號信息加密后以文件方式保存在本地也是可行的,。

本文節(jié)選自作者新書《產(chǎn)品經(jīng)理技術(shù)手冊》，本書定位于讓不懂技術(shù)的產(chǎn)品經(jīng)理從產(chǎn)品經(jīng)理的工作和思考方式切入了解應(yīng)該掌握的技術(shù)原理,。

作者：小風(fēng),，產(chǎn)品經(jīng)理；公眾號：村上風(fēng)

本文由 @小風(fēng)老師 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,。未經(jīng)許可,，禁止轉(zhuǎn)載。

題圖來自Unsplash,，基于CC0協(xié)議,。

該文觀點僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務(wù),。