忘記密碼（密碼找回）

忘記密碼（密碼找回）這個功能可以說是目前所有爲別人提供服務的軟件系統都具備的基礎功能啦!很普遍，因爲總會有人忘記了自己的密碼，這個時候就會選擇忘記密碼功能，根據自己註冊賬號時使用的證件號碼（比如郵箱地址、手機號碼、身份證號等）以某種方式（比如發郵件、發送手機短信息等）來重新設置密碼！這樣我們忘記了密碼的賬號就又可以繼續使用啦！當然如果賬號、密碼、證件號所有東西都忘了的話，那你還是重新註冊一個賬號吧！

密碼找回這個功能很小，也很基礎，但是不可缺少。原理也很簡單，不過會根據不同的業務場景選擇不同的密碼找回流程。不過原理都大同小異，目前主要有兩種方式找回密碼（發送郵件的方式、和發送短信息的方式），這兩種方式還是有所差別的，這裏我們就選擇使用發送郵件的方式來實現密碼找回功能吧！（因爲發郵件的方式免費！！！嘻嘻）。爲了實現這個功能，我們之前專門寫了一篇文章來了解在程序中發送郵件的簡單運用，所以實現這個功能對我們來說只剩下需要了解密碼找回流程的問題啦！

那麼密碼找回的流程應該是怎樣的呢？我們這裏就搞一個簡單的密碼找回流程吧！因爲根據不同的業務場景，我們的找回流程也應該相應的調整。從而達到嚴謹安全的目的。

先來看看我們的密碼找回的簡單流程。

1，點擊忘記密碼按鈕

2，來的密碼找回頁面

3，讓用戶輸入註冊時的郵箱賬號，並點擊確定（控制器收到請求，拿到郵箱地址，給這個郵箱發送重置密碼的連接）給郵箱發送重置密碼連接

4，用戶登錄註冊時使用的郵箱中，點擊收到郵件中的重置密碼鏈接地址來到重置密碼頁面

5，提交重置密碼請求，確定修改新密碼；

整個密碼找回之分了這簡單的五個步驟，比較簡單，不過這裏有兩個地方需要注意。

一、步驟3的時候，我們會給用戶提供的郵箱發送一封郵件，郵件中有我們修改密碼的請求地址，這個請求地址用戶只要點擊就會跳轉到修改密碼頁面。可是我們怎麼才能知道是哪個用戶要修改密碼呢？我們會在郵件中的請求地址中添加上用戶的身份信息，用戶點擊請求地址跳轉到修改密碼頁面後，這個身份信息也會跟到修改密碼頁面並也新密碼一併提交到後臺讓我們修改用戶密碼。不過這個身份信息肯定是不能使用用戶id的，如果把用戶id添加到修改密碼的請求地址中，那麼所有人就都可以看到用戶的用戶id啦，這樣很危險。所有我們在這裏需要創建一個臨時的、一次性的token信息來跟用戶id進行綁定，在發送郵件時臨時生成，修改密碼完成後就刪除這個token。這樣就算是同一個用戶每次修改密碼時使用的token信息也會不同，可以起到一定的保密作用。

二、步驟5的時候，我們後臺修改密碼完成後，應該要刪除跟用戶id綁定的token信息，這樣可以保證這個token是一次性的。就算在修改完密碼後被別人拿到了token信息，也沒有用。當然，我們也可以爲這個token添加一個有效時間，來讓token更加安全。

好，接下來我們就來實現一下密碼找回這個功能吧！

添加忘記密碼頁面，點擊登錄頁面的忘記密碼按鈕來到忘記密碼頁面。

頁面內容很簡單，只有一個郵箱地址輸入框就行，使用登錄頁面修改一下就好了。

因爲只是一個簡單的頁面跳轉，嫌麻煩就沒有寫controller程序，只是在springmvc配置文件中添加一個簡單的配置來進行頁面跳轉。

點擊忘記密碼後跳轉到忘記密碼頁面，添加郵箱地址後點擊確定發送發送郵件請求。

在controller控制器中處理忘記密碼頁面點擊發送郵件的請求。處理後返回發送郵件成功頁面。

在service中添加發送郵件的功能。先判斷用戶填寫的郵箱是否存在，如果不存在就不用發郵件了。如果存在創建token，根據郵箱找到用戶id，再將token保存到t_user_token表中也用戶id進行綁定。t_user_token表是我們新創建的一張數據表，就是爲了保存用戶id與token信息，因爲用戶表中沒有token列，如果添加token列改變用戶表結構的話修改的地方太多，代價太大。所以就創建了t_user_token。主要還是前期設計表結構時沒有考慮周到呀！t_user_token表的正刪改查這裏就不說了，都是自動生成的，很簡單，直接使用就可以了。

數據庫表中保存好對應的token信息後，就可以發送數據啦！這裏我是使用我自己163郵箱賬號爲發送者（記得在程序中使用163的郵箱時需要申請權限哦！！）

將包含token信息的修改密碼請求地址作爲郵件內容，發送到用戶填寫的指定郵箱中，就ok啦！

發送郵件後跳轉到發送郵件成功頁面。並且可以查看郵件。

好，token生成了，郵件也成功發送了。接下來就到了修改密碼啦！

點擊郵件中的鏈接，發送重置密碼請求。來到重置密碼頁面。那麼重置哪個用戶的密碼呢？當然是根據郵件鏈接中的token信息來分辨重置哪個用戶的密碼啦！

在頁面中添加一個隱藏的出入框，輸入框的值就是郵件鏈接中的token信息，這樣在提交修改密碼form表單的時候，就可以將token信息和密碼信息一同提交到後臺的controller更新密碼請求處理方法中啦。

設置新的密碼，點擊確認重置發送更新密碼請求。並在後臺controller中處理這個更新密碼的請求。

更新用戶的密碼後，記得要清除token信息，因爲token是一次性的驗證信息，同一個token信息不應該修改兩次用戶密碼。

在dao中自定義根據token信息更新密碼方法。

編寫sql語句。

點擊確定重置後修改密碼，刪除token，並跳轉到重置密碼成功頁面。

到這裏重置密碼就完成啦。接下來我們就用新的密碼重新登錄一下，試試可不可以登錄。

成功了！！！！

這個功能實現的比較粗糙，很多邏輯不夠嚴謹，大家參考一下就可以啦！

記住我（自動登錄）

那麼接下來呢！我們再來實現一下自動登錄這個功能。自動登錄這個功能相對比較簡單，主要是需要使用cookie來保存用戶信息，用於自動登錄時的身份驗證。

自動登錄這個功能大體可以分爲兩步驟：

一、當用戶第一次勾選了自動登錄複選框，並點擊登錄後，後臺的controller在處理登錄請求時，應該在用戶的身份驗證信息正確後還要將用戶的身份信息再保存一份到客戶端的瀏覽器中（用設置cookie的形式）。這樣客戶端瀏覽器中就擁有了之前選中自動登錄用戶的用戶信息啦，以供下次的自動登錄使用。不過呢！在我們向cookie中設置用戶的身份信息時，出於安全考慮還是不要直接保存用戶名與密碼的好！我們應該也像在忘記密碼時那樣用一個隨機且唯一的token與用戶綁定後，在cookie中保存這個token，這個token就是這個用戶的身份標識。

二、當用戶再次登錄的時候，在登錄頁面login.jsp中應該首先進行自動登錄檢查（1，用戶是否帶了自動登錄的cookie。2，如果帶了，查出用戶信息保存到session中《爲什麼保存到session中？因爲登錄頁面之後的主頁面需要的用戶信息是從session中拿的，之前就是這麼實現的》並且登錄《就是直接跳轉到登錄頁面之後的主頁面》。3，如果沒帶，就正常顯示登錄頁面。）。

當然在進行自動登錄檢查 2）的時候，向服務端查詢用戶信息時有可能會比較耗時，那麼每一次自動登錄時都要等待查詢幾秒的話，用戶體驗會比較差，爲了增加用戶體驗可以使用緩存技術(redis等)。

大概流程我們瞭解了。接下來我們就來實現一下吧。

現在登錄頁面添加一個自動登錄的單選框。

就下來，我們需要修改以前處理登錄功能的controller，在登錄時不光要校驗用戶名與密碼，還要判斷是否使用了自動登錄功能，如果使用了自動登錄功能，我們就要將登錄成功的用戶身份信息保存到客戶端瀏覽器的cookie中，用於下次用戶登錄時可以自動登錄。

出於安全考慮，這裏在向客戶端瀏覽器保存用戶的身份cookie時，使用的也是一個隨機生成的token，在數據庫中創建這個token與用戶的對應關係，這樣一個token信息就相當於用戶信息啦！

這裏有一個地方需要注意一下！！！就是我們要記得設置cookie的訪問路徑cookie.setPath（），而且必須設置路徑爲當前本工程的路徑，否則在客戶端瀏覽器是找不到我們設置的cookie信息的。原因是因爲springMVC出於安全考慮，只允許我們設置當前工程路徑的cookie，否則該cookie就會被springMVC偷偷的刪除掉。而如果我們自己不設置cookie的路徑的話，cookie自己會爲自己帶上一個默認的訪問路徑 “ / ”。這樣就會被刪除！！！！

在service中判斷應該更新用戶的token或者添加token。

哎，由於需要將用戶與自動登錄的這個token關聯起來，但是之前的數據庫表中沒有考慮到這個問題，所以需新創建表來對應這個關係，就將這個對應關係放在前面忘記密碼token對應的表中吧。所以我們需要修改表t_user_token，並且重新逆向生成t_user_token表。好煩！！

好了，已經將用戶的身份token信息保存到了客戶端瀏覽器中的cookie中。接下來我們在下次登陸的時候，使用這個信息來完成自動登錄。

那麼如何在下次登錄的時候實現自動登錄呢？就是在登錄頁面login.jsp中一開始的位置添加腳本，在腳本中取得我們在cookie中保存的token用戶信息，再根據這個token去查詢緩存或者數據庫，看看跟這個token綁定的用戶信息是否存在。如果存在就說明是我們之前正確登錄並點擊了自動登錄的用戶，那麼就可以跳轉到登錄之後的頁面main.jsp來完成自動登錄啦。如果這個token在緩存和數據庫中都查詢不到用戶信息，那麼就說明這個token是有問題的，或者不是我們之前正確登錄並點擊了自動登錄的用戶。那麼就不用做任何處理，直接顯示登錄頁面login.jsp就可以啦。

這樣自動登錄功能就算完成啦！不過這裏還是有個地方需要注意一下。就是我們在根據自動登錄的token查詢用戶信息成功後，直接跳轉到登錄之後的頁面main.jsp時需要注意。這個main.jsp頁面是在工程的WEB_INF目錄下的（WEB_INF目錄下的頁面是不可以直接被訪問的，只能通過controller訪問）。我們直接重定向sendRedirect訪問main.jsp頁面是不允許的。所以這裏我sendRedirect訪問main.html，並新建controller的請求處理類DespatcherController來處理main.html這個請求，在這個請求的處理方法中去訪問main.jsp頁面就可以啦！！嘻嘻！！因爲懶所以有點投機取巧呀！

好了，我們運行系統試試吧。

在登錄時選中自動登錄單選框。點擊登錄。

成功登陸後，退出到首頁，重新登錄。

點擊去登錄頁面，會看到自動發送main.html的請求，說明根據用戶的token取得用戶信息成功啦。

這樣自動登錄就完成啦！

這裏的自動登錄功能很簡單，也很簡陋。只是用於學習，大家在實現這個功能的時候，根據自己項目的需求做相應修改就好。

這裏附上代碼下載地址，用於需要的時候查閱：https://download.csdn.net/download/qq_25106373/11233448

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

到這裏我們的衆籌網項目中的後臺manager程序的相關知識就完成啦，沒有實現的都是一些重複性的增刪改查功能，多多練習就好，沒有必要在這裏浪費篇幅。

衆籌系統架構重構

接下來呢！我們就要去實現給廣大用戶使用的前臺功能啦！不過，前臺的程序的基礎結構跟後臺有點不太一樣。由於後臺manager程序是給管理人員使用的系統，比較小衆，並且訪問的方式也比較單一（統一使用電腦網頁端訪問）。所以後臺的服務多數都是返回直接跳轉到頁面的方式。可是前臺給用戶使用的系統不同，前臺的用戶會很多，訪問方式也多樣化（比如，電腦網頁端、手機app端、平板電腦等），這樣我們就不能再直接返回頁面給客戶端程序啦。我們應該統一返回json數據給客戶端，讓客戶端自己去解析返回數據並顯示。這樣就可以實現一套服務程序同時爲多端客戶端提供服務啦！

這樣我們就需要在我們的系統中再創建war項目，來單獨爲前臺用戶提供可獨立運行的服務。先來看看我們整個衆籌平臺的基礎結構吧。

上圖中的scw-portal項目與scw-restapi項目是在整個衆籌平臺系統重新創建的兩個war項目。scw-portal只負責處理網頁端前臺用戶跳轉頁面的請求，至於頁面中的數據都是從scw-restapi請求獲得的。scw-restapi負責處理並返回所有客戶端需要的json數據。scw-restapi項目、scw-portal項目和scw-manager項目這三個項目都是可以運行的war項目。

scw-manager項目不用多說，只爲衆籌平臺的管理人員提供服務，也就是後臺程序。

scw-restapi項目是爲所有前臺用戶的客戶端提供，統一返回json數據的服務。

scw-portal項目只負責處理網頁端前臺用戶跳轉頁面的請求。由於手機移動app有自己的頁面，不需要服務端返回頁面。但pc網頁端不同，客戶端是瀏覽器，無法保存頁面，所有需要先向scw-portal發送跳轉頁面的請求，然後再獲取需要的json數據。