我不知道什么对你不起作用,但这就是你可以使用 AuthorizationService 的方式。
对于此示例,假设您在启动时定义了一个策略:
services.AddAuthorization(options =>
{
// assume that claimtype of role is role.
options.AddPolicy("MyRolePolicy", policy => policy.RequireClaim("role", "SomeRole"));
});
这意味着受“MyRolePolicy”限制的代码只有在用户具有“SomeRole”角色时才能访问。相当于User.IsInRole("SomeRole")。
在视图中注入服务并为用户测试策略:
@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService _authorizationService
@if ((await _authorizationService.AuthorizeAsync(User, "MyRolePolicy")).Succeeded)
{
}
当您使用自定义授权策略提供者时,策略是通过中间件添加的,例如:
public class AuthorizationPolicyProvider : DefaultAuthorizationPolicyProvider
{
public AuthorizationPolicyProvider(IOptions<AuthorizationOptions> options) : base(options)
{
}
public async override Task<AuthorizationPolicy> GetPolicyAsync(string policyName)
{
// check static policies first
var policy = await base.GetPolicyAsync(policyName);
if (policy == null)
return new AuthorizationPolicyBuilder().AddRequirements(new PermissionRequirement(policyName)).Build();
return policy;
}
}
在此示例中,策略作为权限添加(如果不存在),其中声明类型为 permission,值为策略名称。当我添加策略 MyPermission 时,它将检查声明类型 permission 的值 MyPermission。
在视图中:
@if ((await _authorizationService.AuthorizeAsync(User, "MyPermission")).Succeeded)
{
}
我不确定您所说的“这也不是政策”是什么意思,但授权政策提供者会返回政策。因此,您应该能够验证这些策略。无论是简单的声明类型(例如权限或角色)还是更复杂的带有参数的策略。但名称必须匹配。还要确保注入必要的处理程序、服务等。
更新
您还可以使用要求进行验证:
@if ((await _authorizationService.AuthorizeAsync(User, null, new MinimumAgeRequirement(15))).Succeeded)
MinimumAgeRequirement 是需求本身。
作为documented:
AuthorizeAsync(ClaimsPrincipal, Object, IEnumerable<IAuthorizationRequirement>)
检查用户是否满足
指定资源