ASP.NET Core API：同路由同HTTP动词的多方法实现问题

针对你遇到的同一端点根据角色执行不同逻辑的需求，以下是几种.NET Core中的可行方案：

1. 合并Action，内部判断角色（推荐） #

这是最直接简单的方案，不需要额外配置，将逻辑集中在同一个Action内，前端只需调用同一个接口：

[Authorize]
[HttpPut]
public IActionResult UpdateUser(Input input)
{
    var currentUserId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    var isAdmin = User.IsInRole("Admin");

    // 非管理员只能修改自身数据
    if (!isAdmin && input.Id != currentUserId)
    {
        return Forbid();
    }

    // 确定目标用户ID：管理员用传入的ID，普通用户用自身ID
    var targetUserId = isAdmin ? input.Id : currentUserId;
    
    // 执行更新逻辑
    var updatedUser = _userService.UpdateUser(targetUserId, input);
    return Ok(updatedUser);
}

这种方式的优点是逻辑清晰、维护成本低，避免了路由歧义问题，适合大多数场景。

2. 使用策略授权（Policy-Based Authorization） #

如果权限逻辑需要复用或更复杂，可以将判断逻辑抽离到授权策略中，符合关注点分离原则：

步骤1：注册授权策略 #

在Program.cs中添加自定义策略：

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanUpdateUser", policy =>
        policy.RequireAssertion(async context =>
        {
            var currentUserId = context.User.FindFirstValue(ClaimTypes.NameIdentifier);
            var filterContext = context.Resource as AuthorizationFilterContext;
            if (filterContext == null) return false;

            // 读取请求体中的Input模型（注意异步处理）
            var input = await filterContext.HttpContext.Request.ReadFromJsonAsync<Input>();
            if (input == null) return false;

            // 管理员可修改任意用户，普通用户仅能修改自身
            return context.User.IsInRole("Admin") || input.Id == currentUserId;
        }));
});

步骤2：在Action中应用策略 #

[Authorize(Policy = "CanUpdateUser")]
[HttpPut]
public IActionResult UpdateUser(Input input)
{
    var targetUserId = User.IsInRole("Admin") ? input.Id : User.FindFirstValue(ClaimTypes.NameIdentifier);
    var updatedUser = _userService.UpdateUser(targetUserId, input);
    return Ok(updatedUser);
}

注意：若需要多次读取请求体，需确保请求体可重读（可通过EnableBuffering配置）。

3. 自定义Action约束（解决中间件顺序问题） #

如果坚持拆分Action，可通过自定义Action约束实现，但需确保认证中间件在路由中间件之前执行：

步骤1：调整中间件顺序 #

在Program.cs中保证顺序正确：

// 先执行认证、授权中间件
app.UseAuthentication();
app.UseAuthorization();

// 再执行路由和端点映射
app.UseRouting();
app.MapControllers();

步骤2：自定义角色约束特性 #

public class RoleConstraintAttribute : ActionMethodSelectorAttribute
{
    private readonly string _requiredRole;

    public RoleConstraintAttribute(string requiredRole)
    {
        _requiredRole = requiredRole;
    }

    public override bool IsValidForRequest(RouteContext routeContext, ActionDescriptor actionDescriptor)
    {
        return routeContext.HttpContext.User.IsInRole(_requiredRole);
    }
}

// 可选：针对非管理员的约束
public class NonAdminConstraintAttribute : ActionMethodSelectorAttribute
{
    public override bool IsValidForRequest(RouteContext routeContext, ActionDescriptor actionDescriptor)
    {
        return !routeContext.HttpContext.User.IsInRole("Admin");
    }
}

步骤3：在Action上应用约束 #

[Authorize]
[HttpPut]
[RoleConstraint("Admin")]
public IActionResult UpdateUserAdmin(Input input)
{
    // 管理员更新任意用户逻辑
    var updatedUser = _userService.UpdateUser(input.Id, input);
    return Ok(updatedUser);
}

[Authorize]
[HttpPut]
[NonAdminConstraint]
public IActionResult UpdateUserDefault(Input input)
{
    var currentUserId = User.FindFirstValue(ClaimTypes.NameIdentifier);
    var updatedUser = _userService.UpdateUser(currentUserId, input);
    return Ok(updatedUser);
}

这种方式适合需要将不同角色逻辑完全拆分的场景，但会增加代码复杂度，需谨慎使用。

内容的提问来源于stack exchange，提问作者DatTronGuy