本發(fā)明涉及互聯(lián)網(wǎng)技術(shù)領(lǐng)域，特別涉及一種網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法。

背景技術(shù)：

隨著互聯(lián)網(wǎng)發(fā)展的越來越快，技術(shù)也更新的非常頻繁，比如開發(fā)一個系統(tǒng)的架構(gòu)由最初始的單個服務(wù)器就能處理演變到現(xiàn)在的利用springcloud技術(shù)實現(xiàn)的微服務(wù)，隨著業(yè)務(wù)的越來越復(fù)雜，結(jié)構(gòu)也變得越來越復(fù)雜。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的旨在至少解決所述技術(shù)缺陷之一。

為此，本發(fā)明的目的在于提出一種網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法。

為了實現(xiàn)上述目的，本發(fā)明的實施例提供一種網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法，包括如下步驟：

步驟s1，當(dāng)接收到用戶的服務(wù)請求時，對用戶進(jìn)行登陸是否有效以及該服務(wù)請求是否合法進(jìn)行攔截判斷；

步驟s2，根據(jù)預(yù)先設(shè)置的所有url地址和過濾器應(yīng)忽略的url地址進(jìn)行判斷；

步驟s3，判斷url地址是否為有效地址，并判斷用戶令牌token是否有效；

步驟s4，如果用戶不具備該地址訪問權(quán)限，則過濾返回；如果通過，則對該服務(wù)請求進(jìn)行相關(guān)用戶信息的請求頭的添加。

進(jìn)一步，在所述步驟s3中，所述判斷地址和用戶token是否有效，包括：

注冊匹配器讀取配置文件來獲取需要忽略的地址請求，通過注冊匹配來判斷該服務(wù)請求url地址是否屬于網(wǎng)關(guān)要忽略的地址請求，如果是則進(jìn)行放行；否則繼續(xù)進(jìn)行判斷，獲取請求頭中的token信息，通過token信息從redis數(shù)據(jù)庫中獲取用戶信息；如果返回異常或者返回的用戶信息為空，則請求識別，表示該token信息失效，將錯誤信息返回到客戶端；如果返回的用戶信息有效，則將用戶信息放到請求的屬性attributes中，放行該過濾器。

進(jìn)一步，判斷該服務(wù)請求url地址是否屬于網(wǎng)關(guān)要忽略的地址請求，包括：通過配置文件中的path.skip屬性將需要忽略過濾的地址放進(jìn)忽略權(quán)限匹配校驗器中，然后對訪問的地址進(jìn)行比較，如果訪問地址屬于忽略過濾地址，那么進(jìn)行放行，不再進(jìn)行token的校驗。

進(jìn)一步，所述判斷用戶是否具有該url的訪問權(quán)限，包括：

首先判斷該服務(wù)請求是否進(jìn)行直接放行，如果不屬于則忽略url地址，判斷url地址是否屬于合法或者存在url地址；如果不存在則返回資源無法找到信息，將具有的url地址由注冊匹配器來獲得所擁有的所有合法的url地址，如果請求的url地址存在，則根據(jù)api字段id和用戶的角色進(jìn)行調(diào)用來判斷用戶是否具有該url權(quán)限的方法，并返回結(jié)果，通過結(jié)果判斷是否需要放行；如果結(jié)果中api字段不為空，則將api字段放進(jìn)請求的屬性attributes中。

進(jìn)一步，從請求中獲取前兩個過濾器中保存的屬性attributes，并通過url編碼后保存到請求頭中，然后將請求放行，請求到達(dá)指定的服務(wù)進(jìn)行相應(yīng)的處理。

進(jìn)一步，添加上下文信息，對信息進(jìn)行url編碼，再一次對請求進(jìn)行過濾，對前兩次過濾中的請求頭的信息再一次處理，將信息轉(zhuǎn)化為json格式并對用戶信息進(jìn)行url編碼，然后進(jìn)行放行到對應(yīng)的請求服務(wù)中去。

根據(jù)本發(fā)明實施例的網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法，基于springcloudgateway網(wǎng)關(guān)過濾器的管理技術(shù)，結(jié)合redis，mysql數(shù)據(jù)庫，用于用戶對服務(wù)發(fā)出請求時對用戶進(jìn)行登陸是否有效并且請求是否合法的攔截判斷，根據(jù)預(yù)先設(shè)置的所有url地址，和過濾器應(yīng)該忽略的url地址進(jìn)行判斷，判斷地址是否為有效地址，判斷用戶token是否有效，然后如果用戶不具備該地址訪問的權(quán)限，則過濾返回，如果通過，則對請求進(jìn)行一些有關(guān)用戶信息的請求頭的添加，從而對業(yè)務(wù)進(jìn)行請求，一些用戶相關(guān)的信息可以從請求頭中獲取。本發(fā)明解決了用戶登陸失效判斷以及url請求無效問題，確保發(fā)送到微服務(wù)的請求都是有效的。本發(fā)明采用網(wǎng)關(guān)對用戶的請求進(jìn)行統(tǒng)一的攔截并進(jìn)行url以及用戶登陸是否有效等一系列的判斷來決定是否將請求發(fā)送到指定的微服務(wù)中去，并根據(jù)請求路徑路由到不同的微服務(wù)，保證盡量的簡化開發(fā)。

本發(fā)明附加的方面和優(yōu)點將在下面的描述中部分給出，部分將從下面的描述中變得明顯，或通過本發(fā)明的實踐了解到。

附圖說明

本發(fā)明的上述和/或附加的方面和優(yōu)點從結(jié)合下面附圖對實施例的描述中將變得明顯和容易理解，其中：

圖1為根據(jù)本發(fā)明實施例的網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法的流程圖；

圖2為根據(jù)本發(fā)明實施例的網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法的示意圖。

具體實施方式

下面詳細(xì)描述本發(fā)明的實施例，實施例的示例在附圖中示出，其中自始至終相同或類似的標(biāo)號表示相同或類似的元件或具有相同或類似功能的元件。下面通過參考附圖描述的實施例是示例性的，旨在用于解釋本發(fā)明，而不能理解為對本發(fā)明的限制。

本發(fā)明提出一種網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法，通過判斷地址有效性和token有效性、判斷用戶是否具有該url的訪問權(quán)限、添加上下文信息，對信息進(jìn)行url編碼，可以保證其它服務(wù)收到的請求為安全合法的，以及對添加的請求頭數(shù)據(jù)進(jìn)行url編碼。

如圖1和圖2所示，本發(fā)明實施例的網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法，包括如下步驟：

步驟s1，當(dāng)接收到用戶的服務(wù)請求時，對用戶進(jìn)行登陸是否有效以及該服務(wù)請求是否合法進(jìn)行攔截判斷。

步驟s2，根據(jù)預(yù)先設(shè)置的所有url地址和過濾器應(yīng)忽略的url地址進(jìn)行判斷。

步驟s3，判斷url地址是否為有效地址，并判斷用戶令牌token是否有效。

具體的，判斷地址和用戶token是否有效，包括：

注冊匹配器讀取配置文件來獲取需要忽略的地址請求，通過注冊匹配來判斷該服務(wù)請求url地址是否屬于網(wǎng)關(guān)要忽略的地址請求，如果是則進(jìn)行放行；否則繼續(xù)進(jìn)行判斷，獲取請求頭中的token信息，通過token信息從redis數(shù)據(jù)庫中獲取用戶信息；如果返回異常或者返回的用戶信息為空，則請求識別，表示該token信息失效，將錯誤信息返回到客戶端；如果返回的用戶信息有效，則將用戶信息放到請求request的屬性attributes中，放行該過濾器。

在本發(fā)明的實施例中，判斷該服務(wù)請求url地址是否屬于網(wǎng)關(guān)要忽略的地址請求，包括：通過配置文件中的path.skip屬性將需要忽略過濾的地址放進(jìn)忽略權(quán)限匹配校驗器中，然后對訪問的地址進(jìn)行比較，如果訪問地址屬于忽略過濾地址，那么進(jìn)行放行，不再進(jìn)行token的校驗。

步驟s4，如果用戶不具備該地址訪問權(quán)限，則過濾返回；如果通過，則對該服務(wù)請求進(jìn)行相關(guān)用戶信息的請求頭的添加。

在本步驟中，判斷用戶是否具有該url地址的訪問權(quán)限，包括如下步驟：

首先判斷該服務(wù)請求是否進(jìn)行直接放行，判斷此次過濾是否需要放行忽略地址，如果不屬于則忽略url地址，用url匹配校驗器判斷請求的url地址是否屬于合法或者存在url地址(匹配校驗器通過mysql數(shù)據(jù)庫中的api表將系統(tǒng)api注冊進(jìn)匹配校驗器中，如果url匹配不成功，那么返回資源找不到)；如果不存在則返回資源無法找到信息，然后從請求頭中找到current-context(由第一個過濾器通過token從redis中找到用戶信息保存到該請求頭中)，獲取對應(yīng)的值就是用戶信息，從用戶信息中得到所擁有的角色，然后利用urlapi匹配工具獲取到該路徑所對應(yīng)的apiid，然后根據(jù)id和用戶角色想對應(yīng)的資源校驗服務(wù)發(fā)起請求，通過匹配數(shù)據(jù)庫中role_api表，api_column表得到api字段結(jié)果，如果失敗，說明該用戶不具備該url的訪問權(quán)限，如果成功，那么將用戶具有的api字段信息權(quán)限放入到columnids請求頭中，進(jìn)行放行。

將具有的url地址由注冊匹配器來獲得所擁有的所有合法的url地址，如果請求的url地址存在，則根據(jù)api字段id和用戶的角色進(jìn)行調(diào)用來判斷用戶是否具有該url權(quán)限的方法，并返回結(jié)果，通過結(jié)果判斷是否需要放行；如果結(jié)果中api字段不為空，則將api字段放進(jìn)請求的屬性attributes中。

在本步驟中，從request請求中獲取前兩個過濾器中保存的屬性attributes，并通過url編碼后保存到請求頭中，然后將請求放行，請求到達(dá)指定的服務(wù)進(jìn)行相應(yīng)的處理。

添加上下文信息，對信息進(jìn)行url編碼，再一次對請求進(jìn)行過濾，對前兩次過濾中的請求頭的信息再一次處理，將信息轉(zhuǎn)化為json格式并對用戶信息進(jìn)行url編碼，然后進(jìn)行放行到對應(yīng)的請求服務(wù)中去，返回請求結(jié)果。

根據(jù)本發(fā)明實施例的網(wǎng)關(guān)對用戶請求進(jìn)行統(tǒng)一攔截判斷是否放行的方法，基于springcloudgateway網(wǎng)關(guān)過濾器的管理技術(shù)，結(jié)合redis，mysql數(shù)據(jù)庫，用于用戶對服務(wù)發(fā)出請求時對用戶進(jìn)行登陸是否有效并且請求是否合法的攔截判斷，根據(jù)預(yù)先設(shè)置的所有url地址，和過濾器應(yīng)該忽略的url地址進(jìn)行判斷，判斷地址是否為有效地址，判斷用戶token是否有效，然后如果用戶不具備該地址訪問的權(quán)限，則過濾返回，如果通過，則對請求進(jìn)行一些有關(guān)用戶信息的請求頭的添加，從而對業(yè)務(wù)進(jìn)行請求，一些用戶相關(guān)的信息可以從請求頭中獲取。本發(fā)明解決了用戶登陸失效判斷以及url請求無效問題，確保發(fā)送到微服務(wù)的請求都是有效的。本發(fā)明采用網(wǎng)關(guān)對用戶的請求進(jìn)行統(tǒng)一的攔截并進(jìn)行url以及用戶登陸是否有效等一系列的判斷來決定是否將請求發(fā)送到指定的微服務(wù)中去，并根據(jù)請求路徑路由到不同的微服務(wù)，保證盡量的簡化開發(fā)。

在本說明書的描述中，參考術(shù)語“一個實施例”、“一些實施例”、“示例”、“具體示例”、或“一些示例”等的描述意指結(jié)合該實施例或示例描述的具體特征、結(jié)構(gòu)、材料或者特點包含于本發(fā)明的至少一個實施例或示例中。在本說明書中，對上述術(shù)語的示意性表述不一定指的是相同的實施例或示例。而且，描述的具體特征、結(jié)構(gòu)、材料或者特點可以在任何的一個或多個實施例或示例中以合適的方式結(jié)合。

盡管上面已經(jīng)示出和描述了本發(fā)明的實施例，可以理解的是，上述實施例是示例性的，不能理解為對本發(fā)明的限制，本領(lǐng)域的普通技術(shù)人員在不脫離本發(fā)明的原理和宗旨的情況下在本發(fā)明的范圍內(nèi)可以對上述實施例進(jìn)行變化、修改、替換和變型。本發(fā)明的范圍由所附權(quán)利要求及其等同限定。

總結(jié)

以上是生活随笔為你收集整理的gateway请求拦截_一种网关对用户请求进行统一拦截判断是否放行的方法与流程...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。