我正在创建一个具有不同角色用户的 Web API，与任何其他应用程序一样，我不希望用户A访问用户B的资源，如下所示：
Orders/1（用户A）
Orders/2（用户B）
当然，我可以从请求中获取JWT并查询数据库以检查该用户是否拥有该订单，但这会使我的控制器操作过于繁重。
此示例使用AuthorizeAttribute，但它似乎太广泛了，我将不得不添加大量条件来检查API中所有路由，并查询数据库进行多个连接，最终返回请求是否有效。
更新
对于路由，第一道防线是安全策略，需要特定的声明。
我的问题是关于第二道防线，负责确保用户仅访问其数据/资源。
在这种情况下是否有任何标准方法可供采取？
我的方法是自动限制查询当前认证用户账户所拥有的记录。
我使用一个接口来指示哪些数据记录是与账户相关的。
public interface IAccountOwnedEntity
{
Guid AccountKey { get; set; }
}
同时提供一个接口来注入逻辑，用于确定仓库应该针对哪个账户进行操作。
public interface IAccountResolver
{
Guid ResolveAccount();
}
我今天使用的 IAccountResolver 的实现是基于已认证用户的声明。
public class ClaimsPrincipalAccountResolver : IAccountResolver
{
private readonly HttpContext _httpContext;
public ClaimsPrincipalAccountResolver(IHttpContextAccessor httpContextAccessor)
{
_httpContext = httpContextAccessor.HttpContext;
}
public Guid ResolveAccount()
{
var AccountKeyClaim = _httpContext
?.User
?.Claims
?.FirstOrDefault(c => String.Equals(c.Type, ClaimNames.AccountKey, StringComparison.InvariantCulture));
var validAccoutnKey = Guid.TryParse(AccountKeyClaim?.Value, out var accountKey));
return (validAccoutnKey) ? accountKey : throw new AccountResolutionException();
}
}
然后在仓库内，我将所有返回的记录限制为属于该帐户的记录。
public class SqlRepository<TRecord, TKey>
where TRecord : class, IAccountOwnedEntity
{
private readonly DbContext _dbContext;
private readonly IAccountResolver _accountResolver;
public SqlRepository(DbContext dbContext, IAccountResolver accountResolver)
{
_dbContext = dbContext;
_accountResolver = accountResolver;
}
public async Task<IEnumerable<TRecord>> GetAsync()
{
var accountKey = _accountResolver.ResolveAccount();
return await _dbContext
.Set<TRecord>()
.Where(record => record.AccountKey == accountKey)
.ToListAsync();
}
// Other CRUD operations
}
GetOrderByIdAndUser(long orderId, string username)函数，并从jwt中获取用户名。
如果该用户不拥有该订单，则无法查看，也不需进行额外的数据库调用。
第二种：
首先从数据库中获取订单GetOrderById(long orderId)，然后验证订单的username属性是否与jwt登录用户相同。
如果该用户不拥有该订单，则抛出异常、返回404或其他操作，并且不需要进行额外的数据库调用。void ValidateUserOwnsOrder(Order order, string username)
{
if (order.username != username)
{
throw new Exception("Wrong user.");
}
}
AddPolicy("UserA", builder => builder.RequireClaim("Name", "UserA"))
或者将“UserA”替换为“会计”并将“Name”替换为“角色”。
然后按角色限制控制器方法：
[Authorize(Policy = "UserA")
当然，这又涉及到控制器级别的操作，但您不需要绕过令牌或数据库。这将直接指示哪个角色或用户可以使用哪种方法。
IUserContext是有价值的，该上下文可以在查询域时注入（因此进入repos/无论您在哪里使用linq），并封装其中一些过滤器（IEnumerable<Order> Restrict(this IEnumerable<Order> orders, IUserContext ctx)）。[Authorize(Policy = "MatchingUserPolicy")]，在操作中添加一个额外的策略"ISolemlySwearIHaveDoneImperativeChecks"，然后在MatchUserRequirementsHandler中检查上下文，并在命令式检查已被“声明”时绕过天真的用户/订单匹配检查。ICustomerStore
{
Task<Order[]> GetUserOrders(String userid);
Task<Bool> CanUserSeeOrder(String userid, String orderid);
}