在开始之前，老周先祝各个次元的伙伴们新春快乐、生活愉快、万事如意。
在上一篇水文中，老周介绍了角色授权的一些内容。本篇咱们来聊一个比较实际的问题——把用于授权的角色名称放到外部配置，不要硬编码，以方便后期修改。
由于要配置的东西比较简单，咱们并不需要存在数据库，而是用 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，主要问题是自己写有时候没有官方内置的代码严谨，容易出“八阿哥”。
所以，综合复杂性与灵活性的平衡，在不扩展现有接口的前提下，咱们这个示例是比较好的，至少，咱们可以在配置文件中修改角色列表。
标签：Core,ASP,配置文件,角色,验证,Token,var,授权 From： https://www.cnblogs.com/tcjiaan/p/17065118.html