這節(jié)我們繼續(xù)Go項(xiàng)目的實(shí)戰(zhàn)開發(fā)，首先再看一下項(xiàng)目要實(shí)現(xiàn)的功能的用例圖：

圖片

圖中用戶認(rèn)證相關(guān)的功能我們已經(jīng)開發(fā)完了，在前面的四節(jié)課中詳細(xì)地記述了他們的設(shè)計和開發(fā)過程，這一節(jié)我們行進(jìn)到功能用例的第二大部分--用戶個人信息管理。

前面兩節(jié)我們還埋下了一個扣，說用戶在修改密碼后需要把用戶在所有登錄平臺上的Token和Session全部清除掉，強(qiáng)制用戶在每個平臺上用新密碼重新登錄，這也是一項(xiàng)安全措施。那么這一節(jié)我們就先來開發(fā)用戶密碼的修改/重置，

重置密碼的流程拆解和安全防護(hù)

用戶在登錄態(tài)下修改和重置密碼比較好實(shí)現(xiàn)，很多產(chǎn)品的邏輯是登錄情況下輸入原密碼、新密碼就可以修改，而用戶在無登錄狀態(tài)下做上面這些操作即找回密碼的功能則需要通過讓用戶填寫服務(wù)器發(fā)送給他們的驗(yàn)證碼，進(jìn)行確認(rèn)后才能為用戶修改密碼。

我們這里就直接分析重置密碼的功能吧，這個功能在邏輯實(shí)現(xiàn)上更完善一些，拿來做修改密碼功能也能用。

重置密碼的整個流程中服務(wù)端內(nèi)部做了什么，和客戶端怎么交互的，我用一張順序圖給大家做了梳理。大家先看一下：

圖片

每個產(chǎn)品重置用戶密碼的功能實(shí)現(xiàn)跟這里說的可能有細(xì)微差別，但總體流程應(yīng)該差不多。

• 客戶端首先發(fā)起申請重置密碼的請求，請求中需要提交它的郵箱/手機(jī)號
• 服務(wù)端驗(yàn)證用戶是否存在、是否為正常狀態(tài)，然后生成重置密碼的Token和六位驗(yàn)證碼

以Token為Key，將用戶的ID和驗(yàn)證碼存儲到Redis，用于后續(xù)重置密碼時的安全驗(yàn)證，緩存設(shè)置一個較短的有效期，比如半小時過期

通過郵件/短信的形式把驗(yàn)證碼發(fā)送給用戶

返回重置密碼的Token給客戶端

• 重置密碼操作：客戶端提交用戶輸入的新密碼和驗(yàn)證碼，頭部攜帶Token發(fā)起發(fā)起請求
• 服務(wù)端驗(yàn)證信息后，把用戶密碼設(shè)置為新密碼，然后把用戶在Redis中保存的Session清空，強(qiáng)制把用戶的登錄狀態(tài)踢掉。

• 這里注意一點(diǎn)，因?yàn)樵蹅兊腡oken體系是支持多登錄平臺的，這里重置完密碼后我們需要拿到用戶在所有平臺上的Token和Session信息都清掉，強(qiáng)制用戶重新登錄。

• 服務(wù)端把申請密碼重置時緩存的驗(yàn)證碼Code和重置Token刪掉，防止用戶的重復(fù)請求和惡意用戶。

通過上面順序圖中客戶端與服務(wù)端交互的會話框，我們可以看到密碼重置功能需要兩個接口來完成：

• 申請重置密碼
• 提交重置密碼

那么接下來我?guī)Т蠹乙黄饘懸幌逻@兩個接口，用代碼實(shí)現(xiàn)我們在上面UML順序圖中整理出來的邏輯。

首先我們來看申請重置密碼接口。

申請重置密碼

申請重置密碼功能，第三方對接應(yīng)該是一些郵件或者是SMS短信服務(wù)，這個需要企業(yè)服務(wù)，就直接Mock掉了，大家真正在公司里開發(fā)項(xiàng)目時，記住與郵件對接的邏輯要寫到Library里。

在開始寫代碼前我們再默念一遍邏輯分層的口訣

請求驗(yàn)證和數(shù)據(jù)綁定邏輯 --- Controller

外圍業(yè)務(wù)邏輯 --- 應(yīng)用服務(wù)

核心業(yè)務(wù)邏輯 --- 領(lǐng)域服務(wù)

數(shù)據(jù)訪問邏輯 --- 數(shù)據(jù)訪問層

第三方對接 -- Library（這個本節(jié)暫時用不到）

申請重置密碼時，我們在下發(fā)重置密碼的Token和驗(yàn)證碼前需要在Redis緩存一份，用于后面用戶提交重置密碼時的驗(yàn)證，所以我們先從DAL層的代碼開始。