上次老周和大夥伴們分享了有關按使用者Level授權的技巧,本文咱們聊聊以使用者角色來授權的事。
按使用者角色授權其實更好弄,畢竟這個功能是內部整合的,多數場景下我們不需要擴充套件,不用自己寫處理程式碼。從功能語意上說,授權分為按角色授權和按策略授權,而從程式碼本質上說,角色權授其實是包含在策略授權內的。怎麼說呢?往下看。
角色授權主要依靠 RolesAuthorizationRequirement 類,來看一下原始碼精彩片段回放。
public class RolesAuthorizationRequirement : AuthorizationHandler<RolesAuthorizationRequirement>, IAuthorizationRequirement { public RolesAuthorizationRequirement(IEnumerable<string> allowedRoles) { …… AllowedRoles = allowedRoles; } public IEnumerable<string> AllowedRoles { get; } protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, RolesAuthorizationRequirement requirement) { if (context.User != null) { var found = false; foreach (var role in requirement.AllowedRoles) { // 重點在這裡 if (context.User.IsInRole(role)) { found = true; //說明是符合角色要求的 break; } } if (found) { // 滿足要求 context.Succeed(requirement); } } return Task.CompletedTask; } …… }
這個是不是有點熟悉呢?對的,上一篇博文里老周介紹過,實現 IAuthorizationRequirement 介面表示一個用於授權的必備條件(或者叫必備要素),AuthorizationHandler 負責驗證這些必備要素是否滿足要求。上一篇博文中,老周是把實現 IAuthorizationRequirement 介面和重寫抽象類 AuthorizationHandler<TRequirement> 分成兩部分完成,而這裡,RolesAuthorizationRequirement 直接一步到位,兩個一起實現。
好,理論先說到這兒,下面咱們來過一把程式碼癮,後面咱們回過頭來再講。咱們的主題是說授權,不是驗證。當然這兩者通常是一起的,因為授權的前提是要驗證通過。所以為了方便簡單,老周還是選擇內建的 Cookie 驗證方案。不過這一回不搞使用者名稱、密碼什麼的了,而是直接用 Claim 設定角色就行了,畢竟我們的主題是角色授權。
public class LoginController : Controller { [HttpGet("/login")] public IActionResult Login() => View(); [HttpPost("/login")] public async void Login(string role) { Claim c = new(ClaimTypes.Role, role); ClaimsIdentity id = new(new[] { c }, CookieAuthenticationDefaults.AuthenticationScheme); ClaimsPrincipal p = new ClaimsPrincipal(id); await HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, p); } [HttpGet("/denied")] public IActionResult DeniedAcc() => Content("不好意思,你無權存取");
[HttpGet("/logout")]
public async void Logout()=> await HttpContext.SignOutAsync();
}
無比聰明的你一眼能看出,這是 MVC 控制器,並且實現登入有關的功能:
/login:進入登入頁
/logout:登出
/denied:表白失敗被拒絕,哦不,授權失敗被拒絕後存取
Login 方法有兩個,沒引數的是 GET 版,有引數的是 POST 版。當以 POST 方式存取時,會有一個 role 引數,表示被選中的角色。這裡為了簡單,不用輸使用者名稱密碼了,直接選個角色就登入。
Login 檢視如下:
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers <div> <p>登入角色:</p> <form method="post"> <select name="role"> <option value="admin">管理員</option> <option value="svip" selected>超級會員</option> <option value="gen">普通客戶</option> </select> <button type="submit">登入</button> </form> </div>
select 元素的名稱為 role,正好與 Login 方法(post)的引數 role 相同,能進行模型繫結。
admin 角色表示管理員,svip 角色表示超級VIP客戶,gen 角色表示普通客戶。假設這是一家大型紙尿褲批發店的客戶管理系統。這年頭,連買紙尿褲也要分三六九等了。
下面是該紙尿褲批發店為不同客戶群提供的服務。
[Route("znk")] public class 紙尿褲Controller : Controller { [Route("genindex")] [Authorize(Roles = "gen")] public IActionResult IndexGen() { return Content("普通客戶瀏覽頁"); } [Route("adminindex")] [Authorize(Roles = "admin")] public IActionResult IndexAdmin() { return Content("管理員專場"); } [Route("svipindex")] [Authorize(Roles = "svip")] public IActionResult IndexSVIP() => Content("超級會員殺熟通道"); }
注意上面授權特性,不需要指定策略名稱,只需指定你要求的角色名稱即可。
在應用程式的初始化設定上,咱們設定 Cookie 驗證。
var builder = WebApplication.CreateBuilder(args); builder.Services.AddControllersWithViews(); builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie(opt => { opt.LoginPath = "/login"; opt.AccessDeniedPath = "/denied"; opt.LogoutPath = "/logout"; opt.ReturnUrlParameter = "url"; opt.Cookie.Name = "_XXX_FFF_"; }); var app = builder.Build();
那幾個路徑就是剛才 Login 控制器上的存取路徑。
因為不需要設定授權策略,所以不需要呼叫 AddAuthorization 擴充套件方法。主要是這個方法你在呼叫 AddControllersWithViews 方法時會自動呼叫,所以,如無特殊設定,咱們不用手動開啟授權功能。像 MVC、RazorPages 等這些功能,預設會設定授權的。
假如我要存取紙尿褲批發店的超級會員通道,存取 /znk/svipindex,這時候會跳轉到登入介面,並且 url 引數包含要回撥的路徑。
預設是選中「超級會員」的,此時點選「登入」,就能獲取授權。
如果選擇「普通客戶」,就會授失敗,拒絕存取。
----------------------------------------------------------------------------------------
雖然角色授權功能咱們輕鬆實現了,可是,隨之而來的會產生一些疑問。不知道你有沒有這些疑問,反正老周有。
AuthorizationPolicy 類有個靜態方法—— CombineAsync,這個方法的功能是合併已有的策略。但,咱們重點看這一段:
AuthorizationPolicyBuilder? policyBuilder = null; if (!skipEnumeratingData) { foreach (var authorizeDatum in authorizeData) { if (policyBuilder == null) { policyBuilder = new AuthorizationPolicyBuilder(); } var useDefaultPolicy = !(anyPolicies); // 如果有指定策略名稱,就合併 if (!string.IsNullOrWhiteSpace(authorizeDatum.Policy)) { var policy = await policyProvider.GetPolicyAsync(authorizeDatum.Policy).ConfigureAwait(false); if (policy == null) { throw new InvalidOperationException(Resources.FormatException_AuthorizationPolicyNotFound(authorizeDatum.Policy)); } policyBuilder.Combine(policy); useDefaultPolicy = false; } // 如果指定了角色名稱,呼叫 RequireRole 方法新增必備要素 var rolesSplit = authorizeDatum.Roles?.Split(','); if (rolesSplit?.Length > 0) { var trimmedRolesSplit = rolesSplit.Where(r => !string.IsNullOrWhiteSpace(r)).Select(r => r.Trim()); policyBuilder.RequireRole(trimmedRolesSplit); useDefaultPolicy = false; } // 同理,如果指定的驗證方案,新增之 var authTypesSplit = authorizeDatum.AuthenticationSchemes?.Split(','); if (authTypesSplit?.Length > 0) { foreach (var authType in authTypesSplit) { if (!string.IsNullOrWhiteSpace(authType)) { policyBuilder.AuthenticationSchemes.Add(authType.Trim()); } } } ……
原來,在合併策略過程中,會根據 IAuthorizeData 提供的內容動態新增 IAuthorizationRequirement 物件。這裡出現了個 IAuthorizeData 介面,這廝哪來的?莫急,你看看咱們剛才在 紙尿褲 控制器上應用了啥特性。
[Route("adminindex")] [Authorize(Roles = "admin")] public IActionResult IndexAdmin() { return Content("管理員專場"); }
對,就是它!AuthorizeAttribute,你再看看它實現了什麼介面。
public class AuthorizeAttribute : Attribute, IAuthorizeData
再回憶一下剛剛這段:
var rolesSplit = authorizeDatum.Roles?.Split(','); if (rolesSplit?.Length > 0) { var trimmedRolesSplit = rolesSplit.Where(r => !string.IsNullOrWhiteSpace(r)).Select(r => r.Trim()); policyBuilder.RequireRole(trimmedRolesSplit); …… }
原來這裡面還有玄機,Role 可以指定多個角色的喲,用逗號(當然是英文的逗號)隔開。如
[Route("adminindex")] [Authorize(Roles = "admin, svip")] public IActionResult IndexAdmin() { …… }
你會發現,在 app 上不呼叫 UseAuthorization 擴充套件方法也能使授權生效。因為像 RazorPages、MVC 這些東東還有一個概念,叫 Filter,可以翻譯為「篩選器」或「過濾器」。老周比較喜歡叫過濾器,因為這叫法生動自然,篩選器感覺是機器翻譯。
在過濾器裡,有專門用在授權方面的介面。
同步:IAuthorizationFilter
非同步:IAsyncAuthorizationFilter
在過濾器中,同步介面和非同步介面只實現其中一個即可。如果你兩個都實現了,那隻執行非同步介面。所以,你兩個都實現純屬白淦,畢竟非同步優先。為啥?你看看 ResourceInvoker 類的原始碼就知道了。
switch (next) { case State.InvokeBegin: { goto case State.AuthorizationBegin; } case State.AuthorizationBegin: { _cursor.Reset(); goto case State.AuthorizationNext; } case State.AuthorizationNext: { var current = _cursor.GetNextFilter<IAuthorizationFilter, IAsyncAuthorizationFilter>(); if (current.FilterAsync != null) // 執行非同步方法 { if (_authorizationContext == null) { _authorizationContext = new AuthorizationFilterContextSealed(_actionContext, _filters); } state = current.FilterAsync; goto case State.AuthorizationAsyncBegin; } else if (current.Filter != null) // 執行同步方法 { if (_authorizationContext == null) { _authorizationContext = new AuthorizationFilterContextSealed(_actionContext, _filters); } state = current.Filter; goto case State.AuthorizationSync; } else {
// 如果都不是授權過濾器,直接 End goto case State.AuthorizationEnd; } } case State.AuthorizationAsyncBegin: { Debug.Assert(state != null); Debug.Assert(_authorizationContext != null); var filter = (IAsyncAuthorizationFilter)state; var authorizationContext = _authorizationContext; _diagnosticListener.BeforeOnAuthorizationAsync(authorizationContext, filter); _logger.BeforeExecutingMethodOnFilter( FilterTypeConstants.AuthorizationFilter, nameof(IAsyncAuthorizationFilter.OnAuthorizationAsync), filter); var task = filter.OnAuthorizationAsync(authorizationContext); if (!task.IsCompletedSuccessfully) { next = State.AuthorizationAsyncEnd; return task; } goto case State.AuthorizationAsyncEnd; } case State.AuthorizationAsyncEnd: { Debug.Assert(state != null); Debug.Assert(_authorizationContext != null); var filter = (IAsyncAuthorizationFilter)state; var authorizationContext = _authorizationContext; _diagnosticListener.AfterOnAuthorizationAsync(authorizationContext, filter); _logger.AfterExecutingMethodOnFilter( FilterTypeConstants.AuthorizationFilter, nameof(IAsyncAuthorizationFilter.OnAuthorizationAsync), filter); if (authorizationContext.Result != null) { goto case State.AuthorizationShortCircuit; } // 完成後直接下一個授權過濾器 goto case State.AuthorizationNext; } case State.AuthorizationSync: { Debug.Assert(state != null); Debug.Assert(_authorizationContext != null); var filter = (IAuthorizationFilter)state; var authorizationContext = _authorizationContext; _diagnosticListener.BeforeOnAuthorization(authorizationContext, filter); _logger.BeforeExecutingMethodOnFilter( FilterTypeConstants.AuthorizationFilter, nameof(IAuthorizationFilter.OnAuthorization), filter); filter.OnAuthorization(authorizationContext); _diagnosticListener.AfterOnAuthorization(authorizationContext, filter); _logger.AfterExecutingMethodOnFilter( FilterTypeConstants.AuthorizationFilter, nameof(IAuthorizationFilter.OnAuthorization), filter); if (authorizationContext.Result != null) { goto case State.AuthorizationShortCircuit; } // 完成後直接一下授權過濾器 goto case State.AuthorizationNext; } case State.AuthorizationShortCircuit: { Debug.Assert(state != null); Debug.Assert(_authorizationContext != null); Debug.Assert(_authorizationContext.Result != null); Log.AuthorizationFailure(_logger, (IFilterMetadata)state); // This is a short-circuit - execute relevant result filters + result and complete this invocation. isCompleted = true; _result = _authorizationContext.Result; return InvokeAlwaysRunResultFilters(); } case State.AuthorizationEnd: { goto case State.ResourceBegin; }
程式碼很長,老周總結一下它的執行軌跡:
1、AuthorizationBegin 授權開始
2、AuthorizationNext 下一個過濾器
3、如果是非同步,走 AuthorizationAsyncBegin
如果同步,走 AuthorizationSync
如果都不是,直接走到 AuthorizationEnd
4、非同步:AuthorizationAsyncBegin --> AuthorizationAsyncEnd --> AuthorizationNext(回第2步,有請下一位過濾俠)
同步:AuthorizationSync --> AuthorizationNext(回第2步,有請下一位)
5、AuthorizationEnd 退場,進入 ResourceFilter 主會場
6、在2、3、4步過程中,如果授權失敗或出錯,直接短路,走 AuthorizationShortCircuit
你瞧,是不是同步和非同步只執行一個?
預設的授權過濾器實現 IAsyncAuthorizationFilter,即 AuthorizeFilter 類。所以,授權處理就是在這裡被觸發了。
var policyEvaluator = context.HttpContext.RequestServices.GetRequiredService<IPolicyEvaluator>(); // 先進行驗證 var authenticateResult = await policyEvaluator.AuthenticateAsync(effectivePolicy, context.HttpContext); // 如果允許匿名存取,後面的工作就免了 if (HasAllowAnonymous(context)) { return; } // 驗證過了,再評估授權策略 var authorizeResult = await policyEvaluator.AuthorizeAsync(effectivePolicy, authenticateResult, context.HttpContext, context); if (authorizeResult.Challenged) //沒登入呢,去登入 { context.Result = new ChallengeResult(effectivePolicy.AuthenticationSchemes.ToArray()); } else if (authorizeResult.Forbidden) //授權失敗,拒絕存取 { context.Result = new ForbidResult(effectivePolicy.AuthenticationSchemes.ToArray()); }
但是,這個授權過濾器在 MvcOptions 的 Filters 中沒有啊,它是啥時候弄進去的?這貨不是在 Filters 中設定的,而是在 Application Model 初始化時通過 AuthorizationApplicationModelProvider 類弄進去的。AuthorizationApplicationModelProvider 類實現了 IApplicationModelProvider 介面,但不對外公開。
public void OnProvidersExecuting(ApplicationModelProviderContext context) { if (context == null) { throw new ArgumentNullException(nameof(context)); } if (_mvcOptions.EnableEndpointRouting) { // When using endpoint routing, the AuthorizationMiddleware does the work that Auth filters would otherwise perform. // Consequently we do not need to convert authorization attributes to filters. return; } foreach (var controllerModel in context.Result.Controllers) { var controllerModelAuthData = controllerModel.Attributes.OfType<IAuthorizeData>().ToArray(); if (controllerModelAuthData.Length > 0) { controllerModel.Filters.Add(GetFilter(_policyProvider, controllerModelAuthData)); } foreach (var attribute in controllerModel.Attributes.OfType<IAllowAnonymous>()) { controllerModel.Filters.Add(new AllowAnonymousFilter()); } foreach (var actionModel in controllerModel.Actions) { var actionModelAuthData = actionModel.Attributes.OfType<IAuthorizeData>().ToArray(); if (actionModelAuthData.Length > 0) { actionModel.Filters.Add(GetFilter(_policyProvider, actionModelAuthData)); } foreach (var _ in actionModel.Attributes.OfType<IAllowAnonymous>()) { actionModel.Filters.Add(new AllowAnonymousFilter()); } } } }
而 filter 是在 GetFilter 方法生成的。
public static AuthorizeFilter GetFilter(IAuthorizationPolicyProvider policyProvider, IEnumerable<IAuthorizeData> authData) { // The default policy provider will make the same policy for given input, so make it only once. // This will always execute synchronously. if (policyProvider.GetType() == typeof(DefaultAuthorizationPolicyProvider)) { var policy = AuthorizationPolicy.CombineAsync(policyProvider, authData).GetAwaiter().GetResult()!; return new AuthorizeFilter(policy); } else { return new AuthorizeFilter(policyProvider, authData); } }
RolesAuthorizationRequirement 一步到位,既實現了 IAuthorizationRequirement 介面又實現抽象類 AuthorizationHandler<TRequirement>。它雖然沒有在服務容器中註冊,可服務容器中註冊了 PassThroughAuthorizationHandler 類,有它在,各種實現 IAuthorizationHandler 介面的 Requirement 都能順利執行,看看原始碼。
public class PassThroughAuthorizationHandler : IAuthorizationHandler { …… public async Task HandleAsync(AuthorizationHandlerContext context) { foreach (var handler in context.Requirements.OfType<IAuthorizationHandler>()) { await handler.HandleAsync(context).ConfigureAwait(false); if (!_options.InvokeHandlersAfterFailure && context.HasFailed) { break; } } } }
看,這不就執行了嗎。
至此,咱們就知道這角色授權的流程是怎麼走的了。