Ocelot.JwtAuthorize:一個基於閘道器的Jwt驗證包
Ocelot作為基於.net core的API方關,有一個功能是統一驗證,它的作用是把沒有訪問許可權的請求擋在API閘道器外面,而不是到達API閘道器事端的API時才去驗證;之前我有一篇博文https://www.cnblogs.com/axzxs2001/p/8005084.html,作過說明,這篇博文說明了實現程式碼,今天我把這個實現作了整理,封裝成一個Nuget包,供大家方便呼叫。
Web API的驗證一般是用UserName和Password請求到Token,然後每次請求需要許可權的API介面是把Token帶到請求的Header中,作為憑據,API服端接收到請求後就要對客戶端帶的Token作驗證,檢視Token是否正確,是否過期,如果沒有問題,再對該使用者作權鑑,該使用者是否有許可權訪問本API介面;這樣看來,登入獲取Tokent算一塊,成功登入後,每次帶Token請求又分兩塊:一塊是驗證,一塊是鑑權,所以在Ocelot.JwtAuthorize中一共分三塊。
專案的原始碼位於https://github.com/axzxs2001/Ocelot.JWTAuthorize
Nuget是https://www.nuget.org/packages/Ocelot.JwtAuthorize
使用也非常簡單,首先有統一的配置檔案(閘道器專案中,API專案中,驗證專案中)
1 "JwtAuthorize": { 2 "Secret": "ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890", 3 "Issuer": "gsw", 4 "Audience": "everyone", 5 "PolicyName": "permissionView Code", 6 "DefaultScheme": "Bearer", 7 "IsHttps": false, 8 "Expiration": 50000 9 }
1、閘道器專案中在Startup的ConfigureService方法中注入services.AddOcelotJwtAuthorize()即可。
2、驗證專案中在Startup的ConfigureService方法中注入services.AddTokenJwtAuthorize(),同時驗證專案還有一個作用是分發Token,前提是使用者有正確的使用者名稱密碼,所以要做一個登入的Colloer和Action來實現,注意登入時Claim中的資訊是在API專案中驗證許可權的資訊。
1 readonly ILogger<LoginController> _logger; 2 //ITokenBuilder是用來生成Token的 3 readonly ITokenBuilder _tokenBuilder; 4 public LoginController(ITokenBuilder tokenBuilder, ILogger<LoginController> logger) 5 { 6 _logger = logger; 7 _tokenBuilder = tokenBuilder; 8 9 } 10 [HttpPost] 11 public IActionResult Login([FromBody]LoginModel loginModel) 12 { 13 _logger.LogInformation($"{loginModel.UserName} login!"); 14 if (loginModel.UserName == "gsw" && loginModel.Password == "111111") 15 { 16 var claims = new Claim[] { 17 new Claim(ClaimTypes.Name, "gsw"), 18 new Claim(ClaimTypes.Role, "admin"), 19 20 }; 21 var token = _tokenBuilder.BuildJwtToken(claims); 22 _logger.LogInformation($"{loginModel.UserName} login success,and generate token return"); 23 return new JsonResult(new { Result = true, Data = token }); 24 } 25 else 26 { 27 _logger.LogInformation($"{loginModel.UserName} login faile"); 28 return new JsonResult(new 29 { 30 Result = false, 31 Message = "Authentication Failure" 32 }); 33 } 34 }View Code
3、API專案中在Startup的ConfigureService方法中注入,並且在Controller或Action上加配置檔案中的ProlicyName的配置名稱,本例是permission
1 services.AddApiJwtAuthorize((context) => 2 { 3 //這裡根據context中的Request和User來自定義許可權驗證,返回true為放行,返回fase時為攔截,其中User.Claims中有登入時自己定義的Claim 4 return true; 5 })View Code
1 [Authorize("permission")] 2 [Route("api/[controller]")] 3 [ApiController] 4 public class ValuesController : Controller 5 { 6 //…… 7 }View Code
相關推薦
Ocelot.JwtAuthorize:一個基於閘道器的Jwt驗證包
Ocelot作為基於.net core的API方關,有一個功能是統一驗證,它的作用是把沒有訪問許可權的請求擋在API閘道器外面,而不是到達API閘道器事端的API時才去驗證;之前我有一篇博文https://www.cnblogs.com/axzxs2001/p/8005084.html,作過說明,這篇博文說明
Ocelot.JwtAuthorize:一個基於網關的Jwt驗證包
auth context 分享圖片 mis aud readonly display view clas Ocelot作為基於.net core的API方關,有一個功能是統一驗證,它的作用是把沒有訪問權限的請求擋在API網關外面,而不是到達API網關事端的API時才去驗證;
網路傳輸的中介:代理、閘道器、通道
轉載地址:http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html 代理(Proxy): 一箇中間程式,它可以充當一個伺服器,也可以充當一個客戶機,為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的
eigrp:增強型內部閘道器協議
eigrp是無類別距離向量路由協議 目錄 eigrp是無類別距離向量路由協議 4大元件: 5大資料包: 工作過程: 結構突變: 基本配置: 啟動eigrp 檢視鄰居表 檢視路由表 檢視拓撲表 擴散更新演算法 擴充套件配置 手工彙總--在更新源路
Choerodon 的微服務之路(二):微服務閘道器
本文是 Choerodon 豬齒魚微服務系列文章的第二篇。在《Choerodon的微服務之路(一):如何邁出關鍵的第一步》中,我們瞭解到在微服務架構中,一個完整的單體應用被拆分成多個有著獨立部署能力的業務服務,每個服務可以使用不同的程式語言,不同的儲存介質,來保持最低限度的集中式管理。本篇將
HTTP|通訊資料轉發程式:代理、閘道器和隧道
HTTP 通訊時,除客戶端和伺服器以外,還有一些用於通訊資料轉發的應用程式,例如代理、閘道器和隧道。它們可以配合伺服器工作。 這些應用程式和伺服器的作用是將客戶端的請求轉發給通訊線路上的下一站伺服器和將從那臺伺服器傳送的響應轉發給客戶端。 1>代理
螞蟻金服 mPaaS 服務端核心元件體系概述:移動 API 閘道器 MGS
根據《開篇 | mPaaS 服務端核心元件體系概述》,我們已經初步瞭解 mPaaS 平臺後端各元件的核心架構體系。 而在 mPaaS 服務端眾多元件中,移動 API 閘道器 MGS 是連線移動客戶端與服務端的元件產品。它簡化了移動端與服務端的資料協議和通訊協議,從而能夠顯著提升開發效率和網路通訊效率,是整個
Spring Boot + Spring Cloud 構建微服務系統(七):API服務閘道器(Zuul)
技術背景 前面我們通過Ribbon或Feign實現了微服務之間的呼叫和負載均衡,那我們的各種微服務又要如何提供給外部應用呼叫呢。 當然,因為是REST API介面,外部客戶端直接呼叫各個微服務是沒有問題的,但出於種種原因,這並不是一個好的選擇。 讓客戶端直接與各個微服務通訊,會有以下幾個問題: 客戶端會多次
SpringCloud(3) :微服務閘道器(Zuul)
在一個實際業務當中通常都會呼叫多個服務介面,而每個服務介面的ip/埠or域名都不一樣,這樣在實際呼叫中會變得十分繁瑣,而且當服務介面ip/埠or域名修改後,業務系統也需要進行相應的修改,大大增加了開發維護成本,所以一般的做法都是在多個服務介面上游再新增一層,我們
EIGRP:增強型內部閘道器路由選擇協議詳解
EIGRP:Ciso增強型內部閘道器路由選擇協議 EIGRP簡介: Cisco私有; 無類別距離向量協議; 跨層封裝協議, 封裝於網路層--協議號88; 組播更新:224.0.0.10 支援非等開銷負載均衡
如何手撕一個API 閘道器(API Gateway)?
一、什麼是API Gateway 一個比較普遍的定義如下: API閘道器是一個伺服器,是系統的唯一入口。從面向物件設計的角度看,它與外觀模式類似。API閘道器封裝了系統內部架構,為每個客戶端提供一個定製的API。 API閘道器方式的核心要點是,所有的客戶端和消費端都
13 基於閘道器服務的IP白名單限制訪問(Whitelist IP Restriction)
用Kong配置一個book服務在安裝並啟動Kong之後,使用Kong的管理API埠8001新增一個名稱為book的服務[[email protected] ~]# curl -i -X POST \--url http://localhost:8001/servic
微服務三:API閘道器和驗證
簡介 現有微服務的幾點不足: 1> 對於在微服務體系中、和Consul通訊的微服務來講,使用服務名即可訪問。但是對於手機、web端等外部訪問者仍然需要和N多伺服器互動,需要記憶他們的伺服器地址、埠號等。一旦內部發生修改,很麻煩,而且有時候內部伺服器是不希望外界直
第二篇:使用API閘道器
寫在前面的話,這些文章是在NGINX的官方部落格中發現的。是關於微服務的一系列的文章,本著好東西共享一下,同時也豐富一下自己,把這些翻譯成中文,但是後來發現國內已經有很多人翻譯了,我只能說我的品位還不差,和各位大牛步調還算一致,雖然已經有人翻譯了,但是本著
12 基於閘道器服務的跨源資源共享(CORS)
如果在前面11篇Kong Gateway系列的文章中,你親自動手實驗過用瀏覽器訪問以下地址:http://localhost:8000/v1/books你將無法獲得書籍介面返回的書籍記錄,本篇blog能讓你在瀏覽器中用8000埠或者8443埠能直接訪問書籍的Restful A
18 基於閘道器服務的請求大小限制(Request Size Limiting)
Configure a Service in Kong[[email protected] ~]# curl -i -X POST \--url http://localhost:8001/services/ \--data 'name=book' \--data
圖解HTTP筆記之第五章:代理、閘道器,隧道
相同的ip地址下,由於虛擬主機可以寄存多個不同主機名和域名的web網站,因此在傳送HTTP請求時,必須在Host首部內完整指定主機名或域名的URL。 代理是一種有轉發功能的應用程式,它扮演了位於伺服
03 基於閘道器服務的OAuth2驗證(OAuth2 Authentication Code Grant 授權碼模式)
https://getkong.org/plugins/oauth2-authentication 我們演示還是用books 的Restful api資料介面,把Kong Gateway - 01範例中PostgresSQL中的kong資料庫刪掉, 匯入一個已經配置好
如何使用Golang實現一個API閘道器
你是否也存在過這樣的需求,想要公開一個介面到網路上。但是還得加點許可權,否則被人亂呼叫就不好了。這個許可權驗證的過程,最好越簡單越好,可能只是對比兩個字串相等就夠了。一般情況下我們遇到這種需要,就是在函式實現或者新增一個全域性的攔截器就夠了。但是還是需要自己來寫那部分雖然簡單但是很囉嗦的程式碼。那麼存不存在一
暢購商城(八):微服務閘道器和JWT令牌
> 好好學習,天天向上 > > 本文已收錄至我的Github倉庫**DayDayUP**:github.com/RobodLee/DayDayUP,歡迎Star,更多文章請前往:[目錄導航](https://github.com/RobodLee/DayDayUP) + [暢購商城(一)