這節我們繼續Go項目的實戰開發，首先再看一下項目要實現的功能的用例圖：

圖片

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

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

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

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

那么接下來我帶大家一起寫一下這兩個接口，用代碼實現我們在上面UML順序圖中整理出來的邏輯。

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

申請重置密碼

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

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

請求驗證和數據綁定邏輯 --- Controller

外圍業務邏輯 --- 應用服務

核心業務邏輯 --- 領域服務

數據訪問邏輯 --- 數據訪問層

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

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