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

圖片

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

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

重置密碼的流程拆解和安全防護

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

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

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

圖片

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

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

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

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

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

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

• 這里注意一點，因為咱們的Token體系是支持多登錄平臺的，這里重置完密碼后我們需要拿到用戶在所有平臺上的Token和Session信息都清掉，強制用戶重新登錄。

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

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

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

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

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

申請重置密碼

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

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

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

外圍業(yè)務邏輯 --- 應用服務

核心業(yè)務邏輯 --- 領域服務

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

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

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