在开始之前，老周先祝各个次元的伙伴们新春快乐、生活愉快、万事如意。
在上一篇水文中，老周介绍了角色授权的一些内容。本篇咱们来聊一个比较实际的问题——把用于授权的角色名称放到外部配置，不要硬编码，以方便后期修改。
由于要配置的东西比较简单，咱们并不需要存在数据库，而是用 JSON 文件配置就可以了。将授权策略和角色列表关联起来。比如，老周这里有个 authorRoles.json 文件，它的内容如下：
{ "cust1": { "roles": ["admin", "supperuser"] }, "cust2": { "roles": ["user", "web", "logger"] } }
其中，cust1、cust2 是策略名称，所以上面就配置了两个授权策略。每个策略下有个 roles 属性，它的值是数组，这个数组用来指定此策略下允许的角色列表。故：cust1 策略下允许admin、supperuser两种角色的用户访问；cust2 策略下允许 user、web、logger 角色的用户访问。
在 WebApplicationBuilder 的配置中，咱们可以单独加载 authorRoles.json 文件中的内容，然后根据配置文件内容动态添加授权策略。
1、先把配置文件中的内容读出来。
// 配置文件名 const string roleConfigFile = "authorRoles.json"; // 单独加载配置 IConfigurationBuilder configBuilder = new ConfigurationBuilder(); // 添加配置源，此处是JSON文件 configBuilder.AddJsonFile(roleConfigFile); // 生成配置树对象 IConfiguration myconfig = configBuilder.Build();
此时，myconfig 变量中就包含了 authorRoles.json 文件的内容了。
2、动态添加授权策略。
var builder = WebApplication.CreateBuilder(args); // 根据配置文件的内容来设置授权策略 builder.Services.AddAuthorization(opt => { foreach (IConfigurationSection cc in myconfig.GetChildren()) { var policyName = cc.Key; opt.AddPolicy(policyName, pbd => { // 获取子节点 var roles = cc.GetSection("roles"); // 取出角色名称列表 string[]? roleslist = roles.Get<string[]>(); if (roleslist is not null) { // 添加角色 pbd.RequireRole(roleslist); // 关联验证架构 pbd.AddAuthenticationSchemes(CustAuthenticationSchemeDefault.SchemeName); } }); } });
在读配置的时候，GetChildren 方法会返回两个节点：cust1 和 cust2。然后用 GetSection 再读下一层，即 roles。接着用 Get 方法就能把字符串数组类型的角色列表读出来了。
这里关联了一个验证架构（或叫验证方案），这个验证架构是老周自己写的，主要是为了简单。老周这个示例是用 Web API 的形式呈现的，所以，不用 Cookie，而是用一个简单的 Token，调用时附加在 URL 的查询字符串中传递给服务器。
如果你的项目的 Token 只是在自己项目中用，不用遵守通用标准，你完全可以自己生成。生成方式你看着办，比如用随机字节什么的都行。在 Token 中不要带密码等安全信息。毕竟，Token 这种东西你说安全，也不见得多安全，别人只要拿到你的 Token 就可以代替你访问服务器。当然你会说，我把 Token 加密再传输。其实别人盗你的 Token 根本不需要知道明文，人家只要按照正确的传递方式（如 Query String、Cookies 等），把你加密后的 Token 放上去，也可以冒用你身份的。所以，很多开放平台都会分配给你 App Key 和密钥，并且强调你的密钥必须保管好，不能让别人知道。
下面看看老周自己写的验证。
using Microsoft.AspNetCore.Authentication; using Microsoft.AspNetCore.Http; using System.Threading.Tasks; public class CustAuthenticationHandler : IAuthenticationHandler { #pragma warning disable CS8618 private HttpContext HttpContext { set; get; } private AuthenticationScheme Scheme { get; set; } #pragma warning restore CS8618 public Task<AuthenticateResult> AuthenticateAsync() { // 获取配置的Token IConfiguration appconfig = HttpContext.RequestServices.GetRequiredService<IConfiguration>(); string[]? tks = appconfig.GetSection("custAuthen:tokens").Get<string[]>(); if (tks != null && tks.Length > 0 && HttpContext.Request.Query.TryGetValue("token", out var reqToken)) { // 看看有没有效 if (!tks.Any(t => t == reqToken)) { return Task.FromResult(AuthenticateResult.Fail("未提供有效的Token")); } // 成功 var tickit = new AuthenticationTicket(HttpContext.User, Scheme.Name); return Task.FromResult(AuthenticateResult.Success(tickit)); } return Task.FromResult(AuthenticateResult.NoResult()); } public Task ChallengeAsync(AuthenticationProperties? properties) { HttpContext.Response.StatusCode = StatusCodes.Status401Unauthorized; return Task.CompletedTask; } public Task ForbidAsync(AuthenticationProperties? properties) { HttpContext.Response.StatusCode = StatusCodes.Status403Forbidden; return Task.CompletedTask; } public Task InitializeAsync(AuthenticationScheme scheme, HttpContext context) { if (context == null) throw new ArgumentNullException("context"); HttpContext = context; Scheme = scheme; // 看看验证架构是否一致 if (!scheme.Name.Equals(CustAuthenticationSchemeDefault.SchemeName, StringComparison.OrdinalIgnoreCase)) { throw new Exception("验证架构不一致"); } return Task.CompletedTask; } } public static class CustAuthenticationSchemeDefault { public readonly static string SchemeName = "CustToken"; }
这里老周没有用什么高级算法生成 Token，而是四个字符串（字符串也是随便输入的），表示四个 Token，只要有一个匹配就算是验证成功了。这些 Token 全写在 appsettings.json 里面。
{ "Logging": { …… } }, "AllowedHosts": "*", "custAuthen": { "tokens": [ "662CV08Y4GHXOP3", "BI4C68DLO2HOS0D", "7GSEJ0J8F0246K5", "O9FG6V974KWO9G8" ] } }
所以，访问这四个 Token 的配置路径就是 custAuthen:tokens。
在实现 ForbidAsync 和 ChallengeAsync 方法时，不要调用 HttpContext 的扩展方法 ForbidAsync、ChallengeAsync，因为这些扩展方法内部是通过调用 AuthenticationService 类的 ForbidAsync、ChallengeAsync 方法实现的。最终又会回过头来调用 CustAuthenticationHandler 类的 ChallengeAsync、ForbidAsync 方法。这等于转了一圈，到头来自己调用自己，易造成无限递归。所以这里我只设置一个 Status Code 就好了。
在服务容器上注册一下自定义的验证处理方案。
var builder = WebApplication.CreateBuilder(args); // 添加验证功能 builder.Services.AddAuthentication(opt => { // 注册验证架构（方案） opt.AddScheme<CustAuthenticationHandler>(CustAuthenticationSchemeDefault.SchemeName, displayName: null); });
所以，整个应用程序的初始化代码就是这样。
// 配置文件名 const string roleConfigFile = "authorRoles.json"; // 单独加载配置 IConfigurationBuilder configBuilder = new ConfigurationBuilder(); // 添加配置源，此处是JSON文件 configBuilder.AddJsonFile(roleConfigFile); // 生成配置树对象 IConfiguration myconfig = configBuilder.Build(); var builder = WebApplication.CreateBuilder(args); // 添加验证功能 builder.Services.AddAuthentication(opt => { // 注册验证架构（方案） opt.AddScheme<CustAuthenticationHandler>(CustAuthenticationSchemeDefault.SchemeName, displayName: null); }); // 根据配置文件的内容来设置授权策略 builder.Services.AddAuthorization(opt => { foreach (IConfigurationSection cc in myconfig.GetChildren()) { var policyName = cc.Key; opt.AddPolicy(policyName, pbd => { // 获取子节点 var roles = cc.GetSection("roles"); // 取出角色名称列表 string[]? roleslist = roles.Get<string[]>(); if (roleslist is not null) { // 添加角色 pbd.RequireRole(roleslist); // 关联验证架构 pbd.AddAuthenticationSchemes(CustAuthenticationSchemeDefault.SchemeName); } }); } }); builder.Services.AddControllers(); var app = builder.Build();
之后，是配置中间件管道。为了简单演示，老周没有写用于身份验证的 Web API，而是直接通过 URL 参数来提供当前访问者的角色。实际开发中不能这样做，而应该从数据库中根据用户查询出用户的角色。但此处是为了演示的简单，也是为了延长键盘寿命，就不建数据库了，不然完成这个示例需要一坤年的时间。
不过，咱们知道，授权是用 Claim 来收集信息的，所以，要在授权执行之前收集好信息。我这里用一个中间件，在授权和调用 API 之前执行。
app.Use((context, next) => { var val = context.Request.Query["role"]; string? role = val.FirstOrDefault(); if(role != null) { ClaimsIdentity id = new(new[] { new Claim(ClaimTypes.Role, role) }/*, CustAuthenticationSchemeDefault.SchemeName*/); ClaimsPrincipal p = new(id); context.User = p; } return next(); });
由于 WebApplication 对象默认帮我们调用了 UseRouting 和 UseEndpoints 方法。Web API 在访问时路由的是 MVC 控制器，直接走 End point 路线，会导致咱们上面的 Use 方法设置用户角色的中间件不执行。所以要重新调用 UseRouting 和 UseAuthorization 方法。
app.UseRouting();
app.UseAuthorization();
app.MapControllers();
用一个名为 Demo 的控制器来做验证。
[Route("api/[controller]")] [ApiController] public class DemoController : ControllerBase { [HttpGet("backup")] [Authorize("cust1")] public string Backup() => "备份完成"; [HttpGet("hello/{name}")] [Authorize("cust2")] public string Hello(string name) { return $"你好，{name}"; } }
cust1、cust2 正是咱们前面配置里的节点名称，即策略名称。例如，调用 Hello 方法使用 cust2 授权策略，它配置的角色为 user、web、loggor。
在调用这些 API 时，URL需要携带两个参数：
1、role：用户角色；
2、token：用于验证。
用 http-repl 工具先测试 demo/backup 方法的调用。
get /api/demo/backup?role=web&token=O9FG6V974KWO9G8
上述调用提供的用户角色为 web，根据前面的配置，web 角色应使用 cust2 策略。但 Backup 方法应用的授权策略是 cust1，因此无权访问，返回 403。
咱们改一下，使用角色为 admin 的用户。
get /api/demo/backup?role=admin&token=O9FG6V974KWO9G8
此时，授权通过，返回 200。
访问 Hello 方法也一样，授权策略是 cust2，允许的角色是 user、web、logger。
get /api/demo/hello/小红?role=web&token=BI4C68DLO2HOS0D
授权通过，返回 200 状态码。
用配置文件来设置角色，算是一种简单方案。如果授权需要的角色有变化，只要修改配置文件中的角列表就行。当然，像 cust1、cust2 等策略名称要事先规划好，策略名称不随便改。
有大伙伴会说，干脆连MVC控制器或其方法上应用哪个授权策略也转到配置文件中，岂不美哉！好是好，但不好弄。可以要自己写个授权的 Filter，主要问题是自己写有时候没有官方内置的代码严谨，容易出“八阿哥”。
所以，综合复杂性与灵活性的平衡，在不扩展现有接口的前提下，咱们这个示例是比较好的，至少，咱们可以在配置文件中修改角色列表。