說一下最后一個模塊，授權。用來做訪問控制，控制哪個用戶能干什么。哪個用戶不能干什么？
遵循最小的授權原則，一個用戶只給他必須要的那些權限。
1.你的請求是不是需要權限認證， 有一些請求是根本不需要權限控制的，比如說商品信息搜索和商品信息的查看。
401代表當前請求需要認證，但是你沒認證，有可能是沒攜帶身份認證信息，比如前面講的HttpBasic認證，沒有Autorization的頭，這些情況都要返回401
2.有沒有權限，沒有權限返回403。
401錯誤，發請求的人可以調整請求的信息避免掉401的錯誤的。比如沒帶上身份證明，只要帶上身份證明，那么這個401就不會返回給他了
當返回403的時候，不管客戶端在這個請求上再去做任何的修改，都不會導致這個403可以過去。只有一種情況就是線下去找你的管理員，給他授權了，才能過這個403.
403應該被審計日志記錄下來，這樣可以看到誰在訪問自己沒有權限的東西。
權限控制的兩種方式。
ACL比較常見在linux下用戶的權限
ACL
用戶直接和權限掛鈎。加上權限的字段表，然后重啟下服務，會自動把這個字段創建到數據內。
這樣數據庫內就有了這個字段。
給jojo1配置上度的權限r。給jojo2配置上讀寫的權限rw
寫代碼來控制權限
使用攔截器。所有的Filter都是在interceptor之前執行的。
覆蓋preHandler方法。result是聲明最終的結果，是過還是不過。默認都是讓他過。
這個Interceptor是整個的四個機制的最后。首先要去拿當前的用戶。所有的請求先都必須加身份認證。
獲取請求，根據請求的方法來判斷。
、
下面來寫一個hasPermisson方法。根據請求的方法來判斷當前有沒有權限。
user類創建hasPermission的方法。判斷有沒有權限。
如果是get請求，我的permisson里面有r
如經過不是get請求，就判斷是否有w也就是寫的權限。
首先是限流，先輸出一個1
認證輸出2
審計日志
訪問控制輸出4
配置攔截器
生效的順序是按照add的順序
啟動服務測試
沒有傳身份認證信息
返回的就是代碼這里的提示
傳入用戶jojo1
提示沒有寫的權限
改成jojo2。這是一個有讀寫權限的用戶。
注意這里創建的是jojo3.
返回200，說明認證授權機制基本上已經生效了。
api安全注意的點，有了個簡單的實現。
數據庫內的審計日志
輸出的攔截器的執行順序問題。也是按照我們想要的順序這么來執行的。
