ASP.NET Core自定义[JwtAuthorize]属性在控制器Action未触发问题排查

你的核心问题是：标记了[JwtAuthorize(ApplyAuthorization = true)]的Action未触发自定义授权逻辑，直接返回401；未标记的Action反而正常。结合你的配置，主要原因集中在认证流程顺序冲突、自定义属性与内置授权逻辑的冲突、过滤器注册方式问题这几点，以下是具体排查和解决思路：

一、核心原因推测 #

1. 认证中间件执行早于自定义过滤器
   你配置了JWT Bearer认证中间件，它的执行时机在MVC过滤器之前。你的自定义逻辑是从Session读取令牌后添加到请求头，但认证中间件会先检查请求头中的Authorization字段——此时请求头还没有令牌，直接返回401，导致你的OnAuthorizationAsync代码根本没机会执行。

2. 自定义属性继承AuthorizeAttribute引发内置授权逻辑提前触发
   继承AuthorizeAttribute会自动触发ASP.NET Core内置的授权流程，而你的自定义逻辑还未执行时，内置逻辑就因缺少令牌返回401，覆盖了你的自定义授权逻辑。

3. 全局过滤器与Action属性的实例冲突
   你将JwtAuthorizeAttribute注册为Scoped服务并全局添加，但如果全局注册方式错误（比如直接添加类型而非用ServiceFilter），会导致全局过滤器实例为单例，Action上标记的属性参数（ApplyAuthorization = true）无法覆盖全局默认值，甚至两个实例的执行顺序混乱。

二、排查步骤 #

1. 验证Session与令牌可用性
   在任意正常访问的Action中，先读取Session中的令牌并打印，确认令牌存在且有效：

   var token = HttpContext.Session.GetString("JwtToken");
   Console.WriteLine($"Session Token: {token}");
   

2. 测试移除全局过滤器
   暂时注释Startup中全局添加JwtAuthorizeAttribute的代码，只在Dashboard Action上标记属性，看断点是否能命中。如果能命中，说明全局过滤器与Action属性存在冲突。

3. 检查管道顺序
   确认Startup中中间件顺序正确（Session必须在认证之前）：

   app.UseSession();           // 先启用Session
   app.UseAuthentication();    // 再启用认证
   app.UseAuthorization();     // 最后启用授权
   app.UseEndpoints(endpoints => { ... });
   

三、解决方案 #

方案1：用中间件前置处理Session令牌（推荐） #

将从Session取令牌并添加到请求头的逻辑，放到认证中间件之前的自定义中间件中，确保认证中间件能读取到令牌：

1. 创建自定义中间件：

public class JwtSessionMiddleware
{
    private readonly RequestDelegate _next;

    public JwtSessionMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var token = context.Session.GetString("JwtToken");
        if (!string.IsNullOrEmpty(token) && !context.Request.Headers.ContainsKey("Authorization"))
        {
            context.Request.Headers.Add("Authorization", $"Bearer {token}");
        }

        await _next(context);
    }
}

2. 在Startup中注册中间件（放在认证之前）：

app.UseSession();
app.UseMiddleware<JwtSessionMiddleware>(); // 关键：放在认证中间件之前
app.UseAuthentication();
app.UseAuthorization();

3. 简化自定义授权属性：
   此时无需在过滤器中处理令牌，只需控制是否启用内置授权：

public class JwtAuthorizeAttribute : AuthorizeAttribute
{
    public bool ApplyAuthorization { get; set; } = false;

    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        return !ApplyAuthorization || base.AuthorizeCore(httpContext);
    }
}

方案2：完全自定义过滤器，跳过内置授权逻辑 #

如果必须用过滤器实现，不要继承AuthorizeAttribute，直接实现IAsyncAuthorizationFilter，避免触发内置授权流程：

1. 重写自定义属性：

public class JwtAuthorizeAttribute : Attribute, IAsyncAuthorizationFilter
{
    public bool ApplyAuthorization { get; set; } = false;

    public async Task OnAuthorizationAsync(AuthorizationFilterContext context)
    {
        if (!ApplyAuthorization)
        {
            return;
        }

        var httpContext = context.HttpContext;
        var token = httpContext.Session.GetString("JwtToken");

        if (string.IsNullOrEmpty(token))
        {
            context.Result = new UnauthorizedResult();
            return;
        }

        // 校验令牌过期时间
        var handler = new JwtSecurityTokenHandler();
        var jwtToken = handler.ReadJwtToken(token);
        if (jwtToken.ValidTo < DateTime.UtcNow)
        {
            context.Result = new UnauthorizedResult();
            return;
        }

        // 添加请求头供后续逻辑使用
        httpContext.Request.Headers.Add("Authorization", $"Bearer {token}");
    }
}

2. 正确注册全局过滤器（用ServiceFilter确保Scoped实例）：

services.AddScoped<JwtAuthorizeAttribute>();

services.AddControllersWithViews(options =>
{
    // 全局添加时设置默认ApplyAuthorization=false
    options.Filters.Add(new ServiceFilterAttribute(typeof(JwtAuthorizeAttribute))
    {
        Arguments = new object[] { false }
    });
});

3. 在Dashboard Action上标记：

[JwtAuthorize(ApplyAuthorization = true)]
public IActionResult Dashboard()
{
    // ...
}

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