關于用戶token處理到的坑
當采用前后臺完全分離，以微服務架構的搭建時。在搭建微服務過程中，由于每個服務都是獨立的應用，這樣就會造成一個統一用戶的問題。
當用戶從這個用戶管理系統中登錄后，在其他系統的如何判斷用戶是否已經登錄的問題。
目前常用的有以下幾種方案：
- 1、session 、redis共享處理
- 2、Header存儲token機制
- 3、用戶每個接口加入token參數
其中3方案最簡單，但是要求每個調用接口都需要傳入token參數。我的前期采用的是這種方案。整體測試及使用結果還不錯。
方案2 是要求在進行請求時將token參數加入header中，由于涉及了自定義header參數，因此如果進行跨域訪問時，會過不了Html預檢功能。如果要處理這種預檢，需要先進行options請求的處理。因此我在前臺進行options請求,先將options請求返回200這樣才能保證請求的繼續執行。如果采用同一個域名的情況下，可以避免這種情況。
方案3 在要求我們加入一個spring-session-data-redis的依賴。然后啟動redishttpsession功能。但是我在使用過程中遇到不少問題。但是當多個項目啟動這個功能時，會出現session沖突問題，造成每次請求的sessionid發生變化。
微服務服務間調用傳遞token
微服務間的調用通常我們使用FeignClient來實現。那么如何在調用的時候傳遞token來保證服務間調用的安全校驗呢？
沒錯，我們可以配置一個攔截器。該攔截器的功能就是在請求發出去前在header中添加token。
代碼如下
|
1
2
3
4
5
6
7
|
@Componentpublic class FeignHeaderInterceptor implements RequestInterceptor { @Override public void apply(RequestTemplate template) { template.header(HttpHeaders.AUTHORIZATION, "token"); }} |
RequestInterceptor是feign提供的接口
該接口只有一個方法：
|
1
2
3
|
public interface RequestInterceptor { void apply(RequestTemplate template);} |
這樣被調用的服務就可以在header中拿到token來做校驗了。
以上為個人經驗，希望能給大家一個參考，也希望大家多多支持服務器之家。
原文鏈接：https://blog.csdn.net/tianlong1569/article/details/90699996
