中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

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

一、校驗(yàn)信息時的正則表達(dá)式

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

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

圖6-1 登錄頁面手機(jī)號碼校驗(yàn)示意圖1

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

圖6-2 登錄頁面手機(jī)號校驗(yàn)示意圖2

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

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

二、怎么實(shí)現(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è)置賬號、密碼的有效期。

1. 如何記住密碼

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

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

首先，是基于Cookie的方案。

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

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

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

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

2. 如何設(shè)置賬號、密碼的有效期

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

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

三、單點(diǎn)登錄

公司的產(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)品進(jìn)行登錄認(rèn)證，一定會感到十分不便。對于產(chǎn)品設(shè)計者，也需要設(shè)計重復(fù)的登錄認(rèn)證邏輯。

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

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

1. 直接基于Cookie與Session實(shí)現(xiàn)單點(diǎn)登錄

一般公司的不同產(chǎn)品均位于同一個根域名下，但也不排除有些公司一條業(yè)務(wù)線或一個產(chǎn)品就占用一個單獨(dú)的域名。舉例說明，如果公司服務(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信息。

拿到登錄賬號信息還沒完，還需要驗(yàn)證賬號是否依然處于登錄狀態(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，兩個獨(dú)立的Session是無法知道彼此的登錄狀態(tài)的。為了解決這個問題，就需要借助Session共享技術(shù)。簡單來講，就是可將第一個子域名對應(yīng)的系統(tǒng)與服務(wù)器會話時生成的Session共享給同一個根域名下的其他子域名使用，這樣就可以解決有登錄的Cookie信息，但沒法確定登錄狀態(tài)，從而實(shí)現(xiàn)用戶的免密登錄。

2. 基于CAS方案實(shí)現(xiàn)單點(diǎn)登錄

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

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

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

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

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

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

3. 基于OAuth方案實(shí)現(xiàn)單點(diǎn)登錄

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

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

如圖6-5所示，登錄京東網(wǎng)頁版時，選擇使用微信等第三方賬號授權(quán)登錄，會展示讓微信用戶授權(quán)的二維碼，在用戶掃碼同意授權(quán)以后，微信開放平臺便會驗(yà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ù)器則是專門用于處理認(rèn)證授權(quán)的服務(wù)器，在上面的案例中微信開放平臺提供的認(rèn)證服務(wù)器便充當(dāng)了這個角色。上面的角色還可以繼續(xù)簡化，但至少需要保留客戶端和授權(quán)服務(wù)器。

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

同一時間只允許一個賬號在一臺設(shè)備上登錄，很多產(chǎn)品這樣做是為了避免出現(xiàn)賬號被他人使用但用戶無法察覺的情況。針對這類需求，由于終端的差異，因此存在著不同的實(shí)現(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ù)客戶端提交的賬號進(jìn)行查詢，發(fā)現(xiàn)Token已經(jīng)存在，說明該賬號還處于登錄狀態(tài)，但由于大風(fēng)也向服務(wù)器發(fā)起了請求，所以為了確保大風(fēng)能正常登錄，便會生成一個新Token并將之前的Token信息刪除。

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

結(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ù)器如果能主動向客戶端推送消息，就可以解決上面的問題，下面介紹兩類解決方案。

1. 輪詢與長輪詢

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

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

2. WebSocket

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

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

WebSocket方案的實(shí)現(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)品，用戶在注冊登錄后，可記錄自己的消費(fèi)情況，進(jìn)而形成好的理財習(xí)慣。為了兼顧用戶體驗(yàn)及技術(shù)實(shí)現(xiàn)，一般會設(shè)計為在無網(wǎng)情況下，用戶可以通過離線模式將數(shù)據(jù)記錄在本地，待網(wǎng)絡(luò)恢復(fù)后，再將數(shù)據(jù)上傳至服務(wù)器。

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

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