如何解決微服務(wù)中用戶token處理到的問(wèn)題

這篇文章將為大家詳細(xì)講解有關(guān)如何解決微服務(wù)中用戶token處理到的問(wèn)題，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

關(guān)于用戶token處理到的坑

當(dāng)采用前后臺(tái)完全分離，以微服務(wù)架構(gòu)的搭建時(shí)。在搭建微服務(wù)過(guò)程中，由于每個(gè)服務(wù)都是獨(dú)立的應(yīng)用，這樣就會(huì)造成一個(gè)統(tǒng)一用戶的問(wèn)題。

當(dāng)用戶從這個(gè)用戶管理系統(tǒng)中登錄后，在其他系統(tǒng)的如何判斷用戶是否已經(jīng)登錄的問(wèn)題。

目前常用的有以下幾種方案：

• 1、session 、redis共享處理

• 2、Header存儲(chǔ)token機(jī)制

• 3、用戶每個(gè)接口加入token參數(shù)

其中3方案最簡(jiǎn)單，但是要求每個(gè)調(diào)用接口都需要傳入token參數(shù)。我的前期采用的是這種方案。整體測(cè)試及使用結(jié)果還不錯(cuò)。

方案2 是要求在進(jìn)行請(qǐng)求時(shí)將token參數(shù)加入header中，由于涉及了自定義header參數(shù)，因此如果進(jìn)行跨域訪問(wèn)時(shí)，會(huì)過(guò)不了Html預(yù)檢功能。如果要處理這種預(yù)檢，需要先進(jìn)行options請(qǐng)求的處理。因此我在前臺(tái)進(jìn)行options請(qǐng)求,先將options請(qǐng)求返回200這樣才能保證請(qǐng)求的繼續(xù)執(zhí)行。如果采用同一個(gè)域名的情況下，可以避免這種情況。

方案3 在要求我們加入一個(gè)spring-session-data-redis的依賴。然后啟動(dòng)redishttpsession功能。但是我在使用過(guò)程中遇到不少問(wèn)題。但是當(dāng)多個(gè)項(xiàng)目啟動(dòng)這個(gè)功能時(shí)，會(huì)出現(xiàn)session沖突問(wèn)題，造成每次請(qǐng)求的sessionid發(fā)生變化。

微服務(wù)服務(wù)間調(diào)用傳遞token

微服務(wù)間的調(diào)用通常我們使用FeignClient來(lái)實(shí)現(xiàn)。那么如何在調(diào)用的時(shí)候傳遞token來(lái)保證服務(wù)間調(diào)用的安全校驗(yàn)?zāi)兀?/p>

沒(méi)錯(cuò)，我們可以配置一個(gè)攔截器。該攔截器的功能就是在請(qǐng)求發(fā)出去前在header中添加token。

代碼如下

@Component
public class FeignHeaderInterceptor implements RequestInterceptor {
    @Override
    public void apply(RequestTemplate template) {
        template.header(HttpHeaders.AUTHORIZATION, "token");
    }
}

RequestInterceptor是feign提供的接口

該接口只有一個(gè)方法：

public interface RequestInterceptor {
  void apply(RequestTemplate template);
}

這樣被調(diào)用的服務(wù)就可以在header中拿到token來(lái)做校驗(yàn)了。

關(guān)于“如何解決微服務(wù)中用戶token處理到的問(wèn)題”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。