本文共 4538 字,大约阅读时间需要 15 分钟。
前言
权限管控对于一个系统来说是非常重要的,最熟悉不过的是菜单权限和数据权限,上一节通过Jwt实现了认证,接下来用它实现接口权限的验证,为什么不是菜单权限呢?对于前后端分离而言,称其为接口权限感觉比较符合场景(我是这么理解的);数据权限牵涉到具体业务,这里就不说啦!
正文
对于一些比较简单的系统,访问角色可能只有固定的几种,比如一些产品管理系统,通常只有管理员、维护员、用户三种权限,管理员拥有整个系统的权限,维护员只能访问产品维护相关页面和操作,用户只能访问产品的一些信息,如果类似这种情况,可以直接指定角色的方式进行权限管控,如下:
案例代码直接使用上一节的项目,借用上次认证那块代码(偷懒太明显),如果没看上一篇的小伙伴,去瞅瞅认证那块内容([跟我一起学.NetCore之WebApi接口裸奔有风险(Jwt)]()),随便敲敲代码,这节要用(别说我,我是有苦衷的,想让小伙伴多撸代码~~);如果只是想熟悉知识点,也可以继续往下看的,不废话,直接开始:
注:[Authorize]加在控制器上时,该控制器下所有的接口都受保护;
为了方便测试,如上图所示,增加一个产品控制器,针对不同人员模拟了三个接口,因为接口受到保护,只能通过获取到的Token才能正常访问,这里就不截图演示了。Token调用User中的Login接口获取,详细请参考()。哎呀,还是上个生成Token的代码图:
下面将三个接口指定为不同角色访问,然后运行访问如下:
通过运行测试可知,当增加了对应角色要求之后,尽快Token验证正确,也不能正常调用接口,返回403禁止访问。已经为接口指定了角色,那要如何才能正常调用呢?其实只要在生成Token的时候指定对应角色即可正常访问对应角色的接口,如下代码优化:
如上运行所示,在生成Token时指定了角色为Admin,则这个Token只能访问指定角色为Admin的接口,其他接口是不能访问的。如需要访问其他接口,同样需要在生成Token的时候添加对应的角色,如下:
运行效果这里就不截图演示了,小伙伴们自己试试。
看到这,小伙伴们肯定会问,管理员角色肯定是所有接口都能访问,拿到了Token接下来该咋办,每个接口都加管理员角色对应的特性吗?对于多个角色访问同一个接口的情况,一般会为授权定义策略来实现,如下:
运行效果如下:
小注意点:
多个角色或运算:多个角色只要有其中一个就可以访问;
多个角色且运算:同时得有多个角色才能访问接口;
到这,相信小伙伴已经忍不住要问:不管是角色还是策略的方式,角色都写死了,如果角色动态分配权限咋搞? 是的,上面的方式只适合对权限管控比较简单的项目,绝大数的项目权限肯定是动态分配的,即根据需求,可以针对用户进行访问权限配置,所以接下来就说说这块咋搞。
这次增加的代码稍微有点多,代码都有注释,另外跟着我标注的步骤走,绝对No Problem:
通过以上步骤就完成动态权限的验证了,是不是很给力,这里需要注意一下几个点:
后续用到IHttpContextAccessor需要进行注册;
用户ID在登录的时候要放入Payload中,后续权限验证时要用;
API中使用的策略名称要和定义的一致;
以上案例演示中,在登录的时候模拟权限数据存入内存,对于一些用户数据不大的项目,这种方式还不错,但是对于用户数量比较大或者分布式部署的项目,建议将权限数据存入Redis等缓存数据库中,存取统一的同时也能减少对数据库的访问压力,总不能每次请求过来都从数据库中获取权限数据进行校验。
小知识点:
- 通过获取用户时,访问的接口必须要有Authorize特性,否则只能通过自己解析Token获取;
- 如果在统一受保护的控制器中,有个别接口不需要权限验证,可以为其标注AllowAnonymous特性即可;
校验权限逻辑的完整代码如下:
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{ ////// 权限处理的关键类 /// public class PermissionHandler : AuthorizationHandler{ /// /// 通过IHttpContextAccessor可以获取HttpContext相关信息,但一定要注册服务 /// private readonly IHttpContextAccessor _accessor; ////// 用于判断请求是否带有凭据和是否登录 /// public IAuthenticationSchemeProvider Scheme { get; set; } ////// 构造函数注入 /// 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; //判断资源数据中权限列表中是否有权限 if (!requirement.Permissions.Any()) { //没有直接返回无权限,也可以重新获取权限,实现不退出重新登录就可获取最新权限 context.Fail(); } //判读请求是否拥有凭据,即是否登录 var defaultAuthenticate = await Scheme.GetDefaultAuthenticateSchemeAsync(); if (defaultAuthenticate == null) { context.Fail(); } var result = await httpContext.AuthenticateAsync(defaultAuthenticate.Name); //不为空代表登录成功,为空登录失败 if (result?.Principal != null) { // 获取生成Token时放在payload里的userId string userId = _accessor.HttpContext.User.FindFirst("userId").Value; // 获取当前请求的地址 string requestUrl = httpContext.Request.Path.Value.ToLower(); // 从权限表中查找当前用户是否有当前请求地址的权限 var permission = requirement.Permissions.FirstOrDefault(a => a.Url.ToLower() == requestUrl && a.UserId == userId); // 如果没找到,代表没有权限 if (permission == null) { context.Fail(); } // 如果找到,就继续往下执行 context.Succeed(requirement); } else { // 获取不到对应值就返回无权限 context.Fail(); } } catch (Exception ex) { context.Fail(); } } }}
总结
关于权限验证这块之前大多都是在MVC的授权过滤器中进行完成的, 本来想在说过滤器那块一起说说权限验证的,但感觉关于Jwt的放在一块比较合适。关于Jwt其实还有一个比较关键的点,就是对于Token的处理问题,比如刷新Token、手动失效Token等,这块后续单独整理一篇内容分享。下次先说说过滤器的执行顺序。
关于代码,其实现在在写案例的时候感觉已经开始复杂了,后面整理整理会放在github上,如果急需的可以私下找我,我单独发给小伙伴。
一个被程序搞丑的帅小伙,关注"Code综艺圈",识别关注跟我一起学~~~
撸文不易,莫要白瞟,三连走起~~~~
转载地址:https://www.cnblogs.com/zoe-zyq/p/13801217.html 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!