前言

權(quán)限管控對于一個系統(tǒng)來說是非常重要的，最熟悉不過的是菜單權(quán)限和數(shù)據(jù)權(quán)限，上一節(jié)通過Jwt實現(xiàn)了認(rèn)證，接下來用它實現(xiàn)接口權(quán)限的驗證，為什么不是菜單權(quán)限呢？對于前后端分離而言，稱其為接口權(quán)限感覺比較符合場景(我是這么理解的)；數(shù)據(jù)權(quán)限牽涉到具體業(yè)務(wù)，這里就不說啦！

正文

對于一些比較簡單的系統(tǒng)，訪問角色可能只有固定的幾種，比如一些產(chǎn)品管理系統(tǒng)，通常只有管理員、維護(hù)員、用戶三種權(quán)限，管理員擁有整個系統(tǒng)的權(quán)限，維護(hù)員只能訪問產(chǎn)品維護(hù)相關(guān)頁面和操作，用戶只能訪問產(chǎn)品的一些信息，如果類似這種情況，可以直接指定角色的方式進(jìn)行權(quán)限管控，如下：

案例代碼直接使用上一節(jié)的項目，借用上次認(rèn)證那塊代碼(偷懶太明顯~~~)，如果沒看上一篇的小伙伴，去瞅瞅認(rèn)證那塊內(nèi)容(跟我一起學(xué).NetCore之WebApi接口裸奔有風(fēng)險(Jwt))，隨便敲敲代碼，這節(jié)要用(別說我，我是有苦衷的，想讓小伙伴多擼代碼~~~)；如果只是想熟悉知識點，也可以繼續(xù)往下看的，不廢話，直接開始：

注：[Authorize]加在控制器上時，該控制器下所有的接口都受保護(hù)；

為了方便測試，如上圖所示，增加一個產(chǎn)品控制器，針對不同人員模擬了三個接口，因為接口受到保護(hù)，只能通過獲取到的Token才能正常訪問，這里就不截圖演示了。Token調(diào)用User中的Login接口獲取，詳細(xì)請參考(跟我一起學(xué).NetCore之WebApi接口裸奔有風(fēng)險(Jwt))。哎呀，還是上個生成Token的代碼圖：

下面將三個接口指定為不同角色訪問，然后運行訪問如下：

通過運行測試可知，當(dāng)增加了對應(yīng)角色要求之后，盡快Token驗證正確，也不能正常調(diào)用接口，返回403禁止訪問。已經(jīng)為接口指定了角色，那要如何才能正常調(diào)用呢？其實只要在生成Token的時候指定對應(yīng)角色即可正常訪問對應(yīng)角色的接口，如下代碼優(yōu)化：

如上運行所示，在生成Token時指定了角色為Admin，則這個Token只能訪問指定角色為Admin的接口，其他接口是不能訪問的。如需要訪問其他接口，同樣需要在生成Token的時候添加對應(yīng)的角色，如下：

運行效果這里就不截圖演示了，小伙伴們自己試試。

看到這，小伙伴們肯定會問，管理員角色肯定是所有接口都能訪問，拿到了Token接下來該咋辦，每個接口都加管理員角色對應(yīng)的特性嗎？對于多個角色訪問同一個接口的情況，一般會為授權(quán)定義策略來實現(xiàn)，如下：

運行效果如下：

小注意點：

• 多個角色或運算：多個角色只要有其中一個就可以訪問；

• 多個角色且運算：同時得有多個角色才能訪問接口；

到這，相信小伙伴已經(jīng)忍不住要問：不管是角色還是策略的方式，角色都寫死了，如果角色動態(tài)分配權(quán)限咋搞？?是的，上面的方式只適合對權(quán)限管控比較簡單的項目，絕大數(shù)的項目權(quán)限肯定是動態(tài)分配的，即根據(jù)需求，可以針對用戶進(jìn)行訪問權(quán)限配置，所以接下來就說說這塊咋搞。

這次增加的代碼稍微有點多，代碼都有注釋，另外跟著我標(biāo)注的步驟走，絕對No Problem：

通過以上步驟就完成動態(tài)權(quán)限的驗證了，是不是很給力，這里需要注意一下幾個點：

• 后續(xù)用到IHttpContextAccessor需要進(jìn)行注冊；

  
  

• 用戶ID在登錄的時候要放入Payload中，后續(xù)權(quán)限驗證時要用；

• API中使用的策略名稱要和定義的一致；

以上案例演示中，在登錄的時候模擬權(quán)限數(shù)據(jù)存入內(nèi)存，對于一些用戶數(shù)據(jù)不大的項目，這種方式還不錯，但是對于用戶數(shù)量比較大或者分布式部署的項目，建議將權(quán)限數(shù)據(jù)存入Redis等緩存數(shù)據(jù)庫中，存取統(tǒng)一的同時也能減少對數(shù)據(jù)庫的訪問壓力，總不能每次請求過來都從數(shù)據(jù)庫中獲取權(quán)限數(shù)據(jù)進(jìn)行校驗。

小知識點：

• 通過獲取用戶時，訪問的接口必須要有Authorize特性，否則只能通過自己解析Token獲取；
  

• 如果在統(tǒng)一受保護(hù)的控制器中，有個別接口不需要權(quán)限驗證，可以為其標(biāo)注AllowAnonymous特性即可；

校驗權(quán)限邏輯的完整代碼如下：

using Microsoft.AspNetCore.Authentication; using Microsoft.AspNetCore.Authorization; using Microsoft.AspNetCore.Http; using System; using System.Collections.Generic; using System.Linq; using System.Threading.Tasks;namespace SwaggerDemo.Permission {/// <summary>/// 權(quán)限處理的關(guān)鍵類/// </summary>public class PermissionHandler : AuthorizationHandler<PermissionRequirement>{/// <summary>/// 通過IHttpContextAccessor可以獲取HttpContext相關(guān)信息，但一定要注冊服務(wù)/// </summary>private readonly IHttpContextAccessor _accessor;/// <summary>/// 用于判斷請求是否帶有憑據(jù)和是否登錄/// </summary>public IAuthenticationSchemeProvider Scheme { get; set; }/// <summary>/// 構(gòu)造函數(shù)注入/// </summary>public PermissionHandler(IHttpContextAccessor accessor,IAuthenticationSchemeProvider scheme){this._accessor = accessor;Scheme = scheme;}protected override async Task HandleRequirementAsync(AuthorizationHandlerContext context, PermissionRequirement requirement){try{//拿到HttpContext就無所不能啦var httpContext = _accessor.HttpContext;//判斷資源數(shù)據(jù)中權(quán)限列表中是否有權(quán)限if (!requirement.Permissions.Any()){//沒有直接返回?zé)o權(quán)限，也可以重新獲取權(quán)限，實現(xiàn)不退出重新登錄就可獲取最新權(quán)限context.Fail();}//判讀請求是否擁有憑據(jù)，即是否登錄var defaultAuthenticate = await Scheme.GetDefaultAuthenticateSchemeAsync();if (defaultAuthenticate == null){context.Fail();}var result = await httpContext.AuthenticateAsync(defaultAuthenticate.Name);//不為空代表登錄成功,為空登錄失敗if (result?.Principal != null){// 獲取生成Token時放在payload里的userIdstring userId = _accessor.HttpContext.User.FindFirst("userId").Value;// 獲取當(dāng)前請求的地址string requestUrl = httpContext.Request.Path.Value.ToLower();// 從權(quán)限表中查找當(dāng)前用戶是否有當(dāng)前請求地址的權(quán)限var permission = requirement.Permissions.FirstOrDefault(a => a.Url.ToLower() == requestUrl && a.UserId == userId);// 如果沒找到，代表沒有權(quán)限if (permission == null){context.Fail();}// 如果找到，就繼續(xù)往下執(zhí)行context.Succeed(requirement);}else{// 獲取不到對應(yīng)值就返回?zé)o權(quán)限context.Fail();}}catch (Exception ex){context.Fail();}}} }

總結(jié)

關(guān)于權(quán)限驗證這塊之前大多都是在MVC的授權(quán)過濾器中進(jìn)行完成的，?本來想在說過濾器那塊一起說說權(quán)限驗證的，但感覺關(guān)于Jwt的放在一塊比較合適。關(guān)于Jwt其實還有一個比較關(guān)鍵的點，就是對于Token的處理問題，比如刷新Token、手動失效Token等，這塊后續(xù)單獨整理一篇內(nèi)容分享。下次先說說過濾器的執(zhí)行順序。

關(guān)于代碼，其實現(xiàn)在在寫案例的時候感覺已經(jīng)開始復(fù)雜了，后面整理整理會放在github上，如果急需的可以私下找我，我單獨發(fā)給小伙伴。

一個被程序搞丑的帥小伙，關(guān)注"Code綜藝圈"，識別關(guān)注跟我一起學(xué)~~~

擼文不易，莫要白瞟，三連走起~~~~

總結(jié)

以上是生活随笔為你收集整理的跟我一起学.NetCore之熟悉的接口权限验证不能少(Jwt)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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