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

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

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

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

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

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

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

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

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

總結一下上面兩種情況。在無網絡情況下，App會對手機號碼進行是否符合格式要求的校驗。

那么如何校驗呢？一般可以通過正則表達式。比如在上面的案例中，只要是1開頭的11位數字就是符合要求的，可用正則表達式表示為 /^1[0-9]{10}$/。

二、怎么實現記住密碼功能

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

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

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

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

圖6-4 登錄時的“30天內記住我”功能

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

1. 如何記住密碼

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

常見的技術解決方案有哪些呢？

首先，是基于Cookie的方案。

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

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

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

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

2. 如何設置賬號、密碼的有效期

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

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

三、單點登錄

公司的產品數量不多時，用戶注冊賬號登錄，并結合記住密碼功能，便可滿足用戶短期內均無須再次輸入賬號和密碼的需求。

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

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

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

1. 直接基于Cookie與Session實現單點登錄

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

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

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

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

2. 基于CAS方案實現單點登錄

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

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

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

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

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

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

3. 基于OAuth方案實現單點登錄

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

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

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

圖6-5 京東網頁版登錄功能

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

四、多終端設備的用戶互踢

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

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

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

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

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

1. 輪詢與長輪詢

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

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

2. WebSocket

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

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

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

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

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

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

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