把在微服務里面寫的安全的相關邏輯挪到網關里面來。這樣把安全邏輯和業務邏輯解耦開。那么這些問題就都解決了。
先來看下之前的安全的代碼，首先在之類做了認證，認證服務器去認證，拿這個token去換用戶信息。
認證完成后，又在這里做了個簡單的授權，盤點當前的用戶是不是有讀權限和 寫權限。
在這里還根據resourceId有一個簡單的權限控制，就是我的令牌只能訪問哪些resourceServer
之前基本上做的就是認證和授權，在網關上，所有的請求都要走網關轉到這個微服務上。所以在網關上不光要做認證和授權，之前說的認證機制都要加到網關上，包括限流。
網關上寫代碼-認證
建一個新的filter包
寫一個filter
要繼承ZuulFilter
@Component聲明稱一個Spring的組件
任何一個繼承了ZuulFilter的過濾器都會有四個方法需要覆蓋。
寫一段邏輯判斷過濾器是不是要起作用，這里我們返回true。就是永遠起作用。
run里面是我們真正要寫的業務邏輯
FilterType過濾器的類型，zuul提供了四種過濾器的類型，這里可以寫四個字符串。
從這四個里面挑一個來返回。根據你的實際情況。route是用來控制路由的，一般我們不會自己去寫這個東西，因為zuul替我們做了這個事了。一般我們寫前三個，pre就是在業務邏輯之前會執行過濾器里面的邏輯，也就是run方法里面的邏輯
post是在業務邏輯執行之后，執行run里面的邏輯
error是說在業務邏輯拋出異常之后，我們去會執行run里面的業務邏輯。
大部分情況下我們都是寫pre。我們現在做安全用到的都是pre
filterOrder控制過濾器的執行順序。我們之前也講了 我們幾種安全機制認證、審批、授權 限流是有順序的，就是通過這個字段來控制。這里我們寫一個1
開始寫認證的邏輯
run方法里面是真正的邏輯。這里加上@Slf4j
在我們的訂單服務里面的認證邏輯，他是直接發http請求到認證的服務器上。然后獲取token它的信息。
同樣的我們在filter里面也要做這個事
requestContext是用來獲取請求和響應的。幫我們拿請求響應對象。
request就是拿到了當前的請求。
如果是發往認證服務器的 ，就直接返回了。因為這是去要做驗證的。return null 就是走下一個filter了。
不是token請求的 ，就獲取到請求頭，Authorization。如果請求頭是空 就返回null。在認證這個環節，不管是成功還是失敗都要往下走。在這里不會攔截請求，不讓往下走的。不管認證信息有沒有，也不管認證信息對不對 ，都要往下走。
忽略大小寫來判斷 請求頭是不是以bearer+空格 開頭
tokenInfo
tokenInfo實際上就是調用check_token的返回
我們把他封裝到tokenInfo這樣的類里面
active：標明令牌是不是可用的
client_id：這個令牌是發給哪個客戶端應用的
scope是一個數組
user_name:這個令牌是發給哪個用戶的
aud：就是之前說的resourceId，就是這個令牌可以訪問哪些資源服務器的id的數組。
exp:令牌的過期時間
authorities:用戶對應的所有的權限
在認證服務器上發令牌的時候給所有的用戶都設置了一個權限叫做ROLE_ADMIN
那么最終我們拿到令牌信息的時候，就是這個authorities
現在聲明了一個叫做TokenInfo的對象，來封裝check_token的響應
下面來創建getTokenInfo這個方法
首先是substring截取bearer后面的token
發送請求，在請求頭上要帶clientId、clientSecret，那么我要寫一個HttpHeaders來帶這些信息
因為我這個check_token的服務並不是一個rest服務，他不是發json請求的。所以我要告訴它 我發的是一個表單。
這個信息實際上在我的認證服務器上 沒有注冊。
我們之前只注冊了 orderApp和orderService
現在把gateway也注冊上。直接照抄上面一行就可以。這樣我們就多了一個gateway的應用。這個引用申請的令牌也是只能訪問order-server
最后再帶上令牌的信息。注意這里只能用MultiValueMap，不能用hashMap等，會報錯 跑不通。
然后把所有的信息組裝成一個HttpEntity，HttpEntity的泛型就是param的MultiValueMap
注意這個HttpEntity是Springframework下的
把param和header都放進去。
發送請求
在上面聲明restTemplate
結束