本節開始講認證相關的東西、注意事項，出現問題的對應的解決方案。
先寫用戶註冊的服務，註冊一些用戶信息進去。註冊也是咱們安全體系的一部分mysql
註冊
UserController裏面的create方法
先修改實體類，加上username和password
由於咱們已經在配置文件內配置了generate-ddl爲true，啓動的時候jpa會自動把這兩個屬性加到數據庫裏，這樣就不用咱們本身手動去數據庫里加屬性。
設置主鍵的策略，這裏設置的是根據當前數據庫的類型策略，例如當前是mysql數據庫，那麼就會按照mysql數據庫的策略。自增的字段策略。
sql
@GeneratedValue(strategy = GenerationType.IDENTITY)數據庫
strategy
美 ['strætədʒi]
英 ['strætədʒi]編程
- n.策略；戰略；策劃；戰略部署
- 網絡策略模式；謀略；計謀
建立userInfo對象
複製user這個類，改個名字叫作userInfo。
這裏把@Entity去掉。由於它不是實體，也就是不和數據庫內的表對應。UserInfo用來封裝咱們服務的請求和響應。
保留@Data註解，這回幫咱們生成get和set方法。
UserController裏面凡事用到user的地方都改爲UserInfo
那麼爲何要這麼改呢？這兩個對象從如今來看，屬性是如出一轍的，爲何要分紅兩個呢？這就是編程裏面比較常見的一個概念，關注點分離。
也叫作單一職責原則。任何一個類或者方法它應該只關注一個事，或者說只對一個事負責，只有當這個事變化的時候，我才須要改這個類或者這個方法，若是咱們用User類來做爲Controller的輸入或者輸出，那麼User這個實際上就負責了兩件事。第一件事是跟我麼的數據庫表作映射，這個對象反映出來咱們數據庫有哪些字段，那個字段是主鍵等等這些信息，它是負責跟數據庫裏的表作映射的。
而咱們Controoler裏面的方法 他的用參和出參其實是服務的輸入和輸出。這個其實是兩個概念。 若是咱們在這兩個關注點上用同一個類。都用User的話，那麼User負責的事情就會變多。這個類負責的事情變多就會致使，每個事變化的時候我都要去改User,就會發生一些問題。
好比數據庫結構發生變化的時候，我要去改User，當建立用戶或者修改用戶的服務發生它的輸入和輸出發生變化的時候，我也須要去改User
。這個時候User這個類 它的職責就不清晰了。這不是一個好的編程概念。
舉個例子，例如用戶表裏面加一個積分字段。 這個是一個很常見的需求。
若是我加了積分字段，在Controller裏面還用User對象做爲輸入或者輸出，就意味着個人註冊方法組要的字段裏面也多了個積分字段。可是註冊的時候，基本沒有要求你填寫積分信息的吧？？？因此這就是咱們爲何要建這個UserInfo對象的緣由。這就是關注點分離。
你們在編程的時候也要注意這一點。它會讓你設計出良好的程序。安全
服務層Service
也就是咱們常說的Service層。
在建立Service的實現類
controller層暴露app服務，app服務進來後交給service層，service層再去調用DAO也就是Repository作數據庫操做。這樣職責就徹底區分開了
service層負責實現業務邏輯，Repository專門負責數據庫的操做，通常狀況下Repository也不會有什麼業務邏輯
聲明service內的方法。和controller內是對應的
在Service的Impl類裏面都 實現這些方法。
把實現類聲明稱Spring的Service對象，也就是Spring的一個Bean
Controller內調用Service層的方法
寫Create方法。使用BeanUtils裏面的方法，把傳進來的UserInfo對象的值都複製到User這個對象裏面。
把user對象保存後的id，複製給info對象，再返回回去。這樣前天就能拿到你最終建立的這個用戶的id是多少。
這樣一個簡單的註冊就寫完了網絡
運行測試
返回的狀態碼是200。返回的信息就是註冊的時候填寫的信息，同時還有數據庫最終生成的主鍵自增的id
日誌裏面打印出了insert語句
數據庫內的記錄
app
下面繼續寫認證的邏輯
先明確幾個概念，咱們如今講的是認證，還不是登錄。
認證是驗證用戶的身份是否合法的這樣一個過程。認證這個事 無論 成沒成功，它都要往下走。它和登錄不同。登錄一旦有問題就斷掉了。好比說你登錄的時候用戶名和填錯了。那麼我就直接拋異常了，不會再往下走了。認證的時候，若是你傳進來的用戶身份有問題，仍然要往下走，給下面的審覈去記錄，記錄你此次的身份認證的結果是什麼樣子的。最終這個請求是否是能夠被經過，要由受權來決定。不是由認證來決定的。
明確好了這些概念。就能夠寫代碼。
測試