注冊和登入幾乎是所有産品的必備功能之一，本文作者以細節規則為例，講解了注冊、登入功能背後的設計原理，一起來看一下吧。
注冊和登入功能幾乎是所有産品的必備功能之一。對于使用者，注冊、登入後就可以生成唯一辨別使用者身份的資訊，并基于此資訊同步使用者行為資料。對于平台或公司，使用者注冊時填寫的有效資訊可以有利于後期的精細化營運。
下面以細節規則為例講解注冊、登入功能背後的設計原理。
一、校驗資訊時的正規表達式
如圖6-1所示，這是一款需要使用者提供手機号和驗證碼進行注冊、登入的App。在使用者輸入正确的手機号和驗證碼後，App伺服器會校驗該手機号是否已注冊，若使用者未注冊就點選“登入”按鈕，App會先幫使用者完成注冊，若使用者已注冊，則會成功登入。
再來對比兩種情況。第一種情況，将手機斷網并設為飛行模式。當手機号碼輸入框中沒有任何内容時，發送驗證碼的按鈕處于置灰狀态且顯示“請輸入11位手機号碼”的提示文案。當在手機号碼輸入框中輸入了符合正常手機号碼格式的手機号時，發送驗證碼的按鈕處于可以點選的狀态（顔色由灰變藍）。
圖6-1 登入頁面手機号碼校驗示意圖1
對照圖6-2看看第二種情況。在手機号碼輸入框内輸入了12位數字時，發送驗證碼的按鈕再次處于置灰狀态。将輸入的數字調整為11位，并将首位數字改為2，即調整為不符合正常手機号碼格式的情況，發送驗證碼的按鈕也處于置灰狀态。
圖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是用戶端向伺服器發起請求後，伺服器傳回給用戶端的資訊之一，用戶端會将Cookie儲存下來并在後續接口中帶上該資訊，使伺服器可以判斷是哪個用戶端發起的請求。
在自動登入場景下，使用者首次登入後，賬号和密碼會被記錄在Cookie中，後續登入時，用戶端便從本地取出Cookie中的賬号和密碼發送給伺服器驗證，通過後登入成功，省去了使用者手動重複輸入賬号和密碼的過程。
在Web類型的産品中，則是利用localStorage來實作記住密碼功能的。localStorage是HTML5标準中新加入的一種技術，該技術用于解決Cookie存儲空間比較小的問題。與每條Cookie僅4Kb的容量大小相比，localStorage的容量大小一般會達到5Mb，具體容量大小在不同的浏覽器中會存在差異。并且，儲存在localStorage中的資料是永不過期的，除非進行了主動清空操作。
但把賬号和密碼資訊儲存在本地，存在賬号密碼被洩露及僞造的風險。是以，基于Token的方案便應運而生。大緻過程與基于Cookie的方案類似，隻是Token中無須儲存賬号和密碼資訊，進而提高了安全性。
2. 如何設定賬号、密碼的有效期
首先，依然是借助Cookie方案。在用戶端向伺服器發起請求之後，伺服器給用戶端傳回Cookie時，直接設定好過期時間，一旦過期，用戶端的Cookie資訊就會被清除，後續登入則需要重新驗證。
另外，就是借助Token方案。Token類似于Cookie，也可以設定過期時間。設定過程如下：首次登入時，用戶端将賬号和密碼發送給伺服器，伺服器建立refresh token和token兩個參數，将它們綁定，并設定不同的過期時間（一般可将token參數的過期時間設定得更早），後續登入隻需帶着Token即可校驗。Token過期了以後，用戶端就會向伺服器重新申請Token，此時會先比對之前的refresh token，比對後便生成新的token替換掉之前refresh token綁定的token，并将新的token傳回給用戶端，後續用戶端發送請求時，帶上新的token即可，于是使用者的登入狀态便是一直可用的，直到token和refresh token參數都過期後，使用者才需要重新輸入賬号和密碼。
三、單點登入
公司的産品數量不多時，使用者新增賬號登入，并結合記住密碼功能，便可滿足使用者短期内均無須再次輸入賬号和密碼的需求。
但公司産品數量增加後，依然會讓使用者感受到注冊登入過程的煩瑣。比如，騰訊、阿裡這類大型公司旗下有衆多産品，産品之間往往會産生關聯，如果使用者在使用其中某款産品時需要跳轉到其他産品進行登入認證，一定會感到十分不便。對于産品設計者，也需要設計重複的登入認證邏輯。
解決這類問題的技術方案叫單點登入，英文全稱是Single Sign On，縮寫是SSO。這裡有一個誤區，因為很多産品經理一直以為，同一時間隻允許一個賬号在一台裝置上登入的需求就是單點登入，但實際上單點登入是指産品中存在多套不同的系統，并且這些系統之間彼此是可信任的，隻需讓使用者登入一次，後續便可直接登入産品中的任一系統。
目前市面上最主流的單點登入方案實作思路，要麼是基于Cookie和Session自己搭建，要麼是借助現成架構實作。
1. 直接基于Cookie與Session實作單點登入
一般公司的不同産品均位于同一個根域名下，但也不排除有些公司一條業務線或一個産品就占用一個單獨的域名。舉例說明，如果公司伺服器域名為example.com，且存在兩個系統對應的子域名為big.example.com及huge.example.com，在提供了登入功能的情況下，使用者如果要打開這兩個域名對應的系統頁面，是需要分别登入的。那麼怎樣才能讓使用者在登入了其中一個系統後，打開另一個域名對應的系統時無須重複登入呢？
借助前面講解過的Cookie知識，如果使用者登入其中一個系統，在用戶端本地記錄下使用者登入的Cookie資訊，下次使用者依然在同一端打開另一個系統登入，是不是可以将之前使用者本地儲存的Cookie資訊拿過來直接用呢？遺憾的是，Cookie的使用不支援跨域，即不能直接拿Cookie中關于big.example.com域名的賬号資訊直接登入huge.example.com。那麼，如何解決這個問題呢？好在設定Cookie時，除了可以設定目前域的資訊，還可以設定對應的頂級域名，即example.com，在子域中又可以通路頂級域中的Cookie資訊。
拿到登入賬号資訊還沒完，還需要驗證賬号是否依然處于登入狀态，此時就要借助Session來完成了。
使用者在某個子域名登入後，伺服器可在資料庫中儲存Session資訊，其中就記錄了登入狀态。隻要登入狀态尚未結束，便可根據Cookie找到Session，保持之前的登入狀态。具體如何根據Cookie找到Session呢？例如，使用者在子域名big.example.com登入後，儲存的是cookie1并生成對應的session1，然後在子域名huge.example.com登入，儲存的是cookie2并生成對應的session2，兩個獨立的Session是無法知道彼此的登入狀态的。為了解決這個問題，就需要借助Session共享技術。簡單來講，就是可将第一個子域名對應的系統與伺服器會話時生成的Session共享給同一個根域名下的其他子域名使用，這樣就可以解決有登入的Cookie資訊，但沒法确定登入狀态，進而實作使用者的免密登入。
2. 基于CAS方案實作單點登入
上面的方案已經能夠解決不同産品歸屬同一頂級域名下情況的登入問題，但如果各個業務線域名都是獨立的，那怎樣實作單點登入呢？下面介紹市面上比較成熟的開源解決方案CAS。
在實作CAS這套方案時，除了需要提供正常的業務系統，還需要一個專門負責認證使用者的系統，用于存儲登入使用者的辨別。使用者在登入其他系統時，借助已存儲的辨別進行驗證，這時使用者無須再次登入。在整套CAS方案中，認證系統被稱為CAS Server，業務系統被稱為CAS Client。
實作過程大緻可以分為兩個環節，一是初次登入，二是後續登入。
下面通過案例進行說明。假定某個集團公司叫小風科技集團，旗下的子公司分别叫中風科技發展有限公司和大風科技發展有限公司。中風科技發展有限公司主營業務是線上社交類電商，大風科技發展有限公司主營業務是線上醫療。兩家公司原本獨立營運，産品研發分離，域名也是獨立申請的。因為戰略方向上的調整，兩家子公司的業務需要産生關聯，需要進行産品整合，整合任務之一就是實作系統的單點登入。
先說初次登入。使用者在使用子公司中風科技發展有限公司的産品時，之前登入時會直接請求伺服器，改造為CAS模式後，則會變成先去請求CAS Server，若無法找到Cookie資訊，則判定為初次登入，然後提示使用者輸入賬号和密碼進行登入。完成後，CAS Server便将登入資訊（包括登入狀态）一并寫入伺服器Session中，并記錄下登入的Cookie資訊。此外，它還會在登入成功後，生成一個叫作ST（Service Ticket）的内容，ST會在CAS Server和業務系統之間做來回的雙向驗證，雙方确認無誤後，首次登入就成功了。
再說後續登入。使用者想要通路其他業務系統時，也會先将登入資訊送出給CAS Server，待找到比對的Cookie和Session資訊，并經曆ST的雙向驗證通過，就可以實作後續使用者登入其他業務系統時，無須再次輸入賬号和密碼便能直接登入的需求。
3. 基于OAuth方案實作單點登入
OAuth實際上是一種開放協定。通過這種協定，可以讓第三方應用擷取到使用者在某一個平台存儲的與個人資訊相關的資源，并且在擷取這些資訊時，不需要使用者提供賬号和密碼。
在講解怎麼樣借助OAuth方案實作單點登入前，先講講OAuth協定的授權。
如圖6-5所示，登入京東網頁版時，選擇使用微信等第三方賬号授權登入，會展示讓微信使用者授權的二維碼，在使用者掃碼同意授權以後，微信開放平台便會驗證使用者身份是否正确，如果正确，會生成一個臨時的憑證給使用者，使用者再拿着這個臨時憑證去微信開放平台換取access_token（注意這裡的access_token是OAuth 2.0協定中用戶端通路資源伺服器時需要帶上的令牌，有了這個令牌說明使用者已經同意授權了）。到這一步後，基本上就已經完成了授權登入的過程。當然，後面還需要通過從微信擷取到的使用者資訊來生成會話。
圖6-5 京東網頁版登入功能
在整個互動流程上，OAuth協定中涉及4個不同的角色，分别是resource owner（資源擁有者）、resource server（資源伺服器）、client（用戶端）、authorization server（授權伺服器），不同的角色會起到不同的作用。資源擁有者代表使用者資訊歸屬于誰，在上面的案例中資源擁有者就是微信使用者。資源伺服器是存儲授權後通路網頁的使用者資訊的伺服器，比如微信伺服器。用戶端即發起通路的用戶端。授權伺服器則是專門用于處理認證授權的伺服器，在上面的案例中微信開放平台提供的認證伺服器便充當了這個角色。上面的角色還可以繼續簡化，但至少需要保留用戶端和授權伺服器。
四、多終端裝置的使用者互踢
同一時間隻允許一個賬号在一台裝置上登入，很多産品這樣做是為了避免出現賬号被他人使用但使用者無法察覺的情況。針對這類需求，由于終端的差異，是以存在着不同的實作方式。
下面先來梳理場景。既然是端對端的通路過程，假定使用者小風使用A賬号在某個浏覽器或App中登入，此時向伺服器發起請求，伺服器就會建立一個Session用于保持與用戶端之間的會話狀态。與此同時，伺服器會基于用戶端傳來的一些參數（比如UUID、MAC位址等裝置唯一辨別）來生成Token，并将該Token與賬号綁定，儲存在伺服器。另一個使用者大風，這時也使用同樣的賬号A在不同的裝置中登入，也同樣會向伺服器發起請求，伺服器則會根據用戶端送出的賬号進行查詢，發現Token已經存在，說明該賬号還處于登入狀态，但由于大風也向伺服器發起了請求，是以為了確定大風能正常登入，便會生成一個新Token并将之前的Token資訊删除。
在使用者登入後，伺服器還需要通知前面登入的使用者被擠出登入的事實。
結合前面所學的網絡請求相關知識，無論是移動端還是Web端，在與伺服器互動的過程中，均為用戶端發起請求，伺服器響應并傳回資訊給用戶端。采用這種方式意味着，雖然前面登入的使用者明明已經被後面登入的使用者“擠”了下去，但還是得通過某個特定的操作，向伺服器發起請求，伺服器查詢到新使用者使用同一個賬号登入，才會為前面的使用者登出登入。于是，就會出現在一段時間内，存在兩個使用者同時登入的狀态。
是以，伺服器如果能主動向用戶端推送消息，就可以解決上面的問題，下面介紹兩類解決方案。
1. 輪詢與長輪詢
輪詢，可以被了解為在用戶端，通過定時任務，定時向伺服器發起請求，伺服器收到請求後根據請求的資訊進行響應。采用這種方式，有利有弊，優點是技術實作友善，缺點是會産生大量無效請求，加重網絡負載，甚至還會造成伺服器性能的浪費。
為了減少不必要的請求，便出現了長輪詢。長輪詢與輪詢的不同之處在于，輪詢時伺服器收到用戶端的請求後會立即響應，長輪詢時伺服器收到用戶端的請求後不立即響應，而是會暫時保持發起請求後的連接配接狀态，直到伺服器得到用戶端想要的結果後才通知用戶端，進而減少向伺服器發起請求的次數。
2. WebSocket
無論是輪詢還是長輪詢，都基于HTTP協定，該協定最大的缺點是無法做到伺服器向用戶端主動推送消息。為了克服這一缺點，下面将引出WebSocket方案。
WebSocket也是一種網絡通信協定，但WebSocket協定與HTTP協定不同，其伺服器與用戶端之間可以雙向互推消息。它最常見的應用場景便是即時通信、視訊網站彈幕、線上協同文檔等。
WebSocket方案的實作原理大緻如下：用戶端發起HTTP協定請求到伺服器，并在請求頭中附加Upgrade: WebSocket資訊來表明将協定更新為WebSocket，伺服器收到請求後傳回允許用戶端切換協定的響應資訊 switching，此時雙友善以WebSocket方式開啟了通信管道，直到任意一方決定主動關閉。
五、離線登入是怎麼一回事
離線登入指沒有網絡或伺服器出現故障時，使用者依然可以正常登入并使用産品。比如，對于随手記記賬産品，使用者在注冊登入後，可記錄自己的消費情況，進而形成好的理财習慣。為了兼顧使用者體驗及技術實作，一般會設計為在無網情況下，使用者可以通過離線模式将資料記錄在本地，待網絡恢複後，再将資料上傳至伺服器。
想要實作離線登入，最好使用者曾經采用聯網的方式登入過産品，確定用戶端本地儲存了使用者的Cookie資訊，甚至還可以緩存一部分軟體使用過程中的資料（比如剛才的記賬資訊），也就是通過本地資料持久化的方式進行實作，Cookie資訊便是其中一種資料持久化方式。除此之外，将賬号資訊加密後以檔案方式儲存在本地也是可行的。
本文節選自作者新書《産品經理技術手冊》，本書定位于讓不懂技術的産品經理從産品經理的工作和思考方式切入了解應該掌握的技術原理。
作者：小風，産品經理；公衆号：村上風
本文由 @小風老師 原創釋出于人人都是産品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。