.NET 6中如何捕获自定义IAuthorizationFilter抛出的异常到ExceptionFilterAttribute

问题根源 #

.NET的过滤器管道执行有固定顺序：Authorization过滤器 → Resource过滤器 → Action过滤器 → Exception过滤器。ExceptionFilterAttribute属于Exception过滤器阶段，仅会处理Action执行阶段（及之后）抛出的异常；而Authorization过滤器在更早的阶段执行，抛出的异常不会进入Exception过滤器的处理流程。

另外，IOrderedFilter的Order参数仅对同类型过滤器生效，不同类型的过滤器仍遵循管道阶段优先级，所以给ExceptionFilter设置Order=1也无法让它在AuthorizationFilter之前执行。

解决方案 #

方案1：使用全局异常处理中间件（推荐） #

全局中间件能捕获整个请求管道的异常，包括Authorization阶段的异常，只需在Program.cs中添加：

builder.Services.AddControllers();

// 配置全局异常处理
app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionFeature = context.Features.Get<IExceptionHandlerPathFeature>();
        var exception = exceptionFeature?.Error;

        // 构建标准化错误响应（可复用原ExceptionHandlingAttribute的逻辑）
        var problemDetails = new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Title = "服务器错误",
            Detail = exception?.Message,
            Instance = context.Request.Path
        };

        // 针对授权异常单独处理
        if (exception is AuthorizationException authEx)
        {
            problemDetails.Status = StatusCodes.Status403Forbidden;
            problemDetails.Title = "授权失败";
            problemDetails.Detail = authEx.Message;
        }

        context.Response.StatusCode = problemDetails.Status.Value;
        context.Response.ContentType = "application/problem+json";
        await context.Response.WriteAsJsonAsync(problemDetails);
    });
});

app.UseRouting();
app.UseAuthorization();
app.MapControllers();

方案2：在AuthorizationFilter中手动处理异常 #

修改自定义EntityAuthorizationFilter，在校验逻辑中捕获异常并直接返回错误响应：

public class EntityAuthorizationFilter : IAuthorizationFilter, IOrderedFilter
{
    public int Order { get; set; } = 2;

    public void OnAuthorization(AuthorizationFilterContext context)
    {
        try
        {
            // 你的授权校验逻辑
            if (!ValidateAuthorization(context))
            {
                throw new AuthorizationException("无访问该资源的权限");
            }
        }
        catch (Exception ex)
        {
            // 构建错误响应（可复用原ExceptionHandling的公共逻辑）
            var statusCode = ex is AuthorizationException ? StatusCodes.Status403Forbidden : StatusCodes.Status500InternalServerError;
            var title = ex is AuthorizationException ? "授权失败" : "服务器错误";

            context.Result = new ObjectResult(new ProblemDetails
            {
                Status = statusCode,
                Title = title,
                Detail = ex.Message
            })
            {
                StatusCode = statusCode
            };
        }
    }

    private bool ValidateAuthorization(AuthorizationFilterContext context)
    {
        // 替换为实际授权校验逻辑
        return false;
    }
}

方案3：使用.NET 6+的IExceptionHandler接口（现代方式） #

1. 实现自定义异常处理器：

public class CustomExceptionHandler : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
    {
        var problemDetails = new ProblemDetails();

        if (exception is AuthorizationException authEx)
        {
            problemDetails.Status = StatusCodes.Status403Forbidden;
            problemDetails.Title = "授权失败";
            problemDetails.Detail = authEx.Message;
        }
        else
        {
            problemDetails.Status = StatusCodes.Status500InternalServerError;
            problemDetails.Title = "服务器错误";
            problemDetails.Detail = exception.Message;
        }

        httpContext.Response.StatusCode = problemDetails.Status.Value;
        httpContext.Response.ContentType = "application/problem+json";
        await httpContext.Response.WriteAsJsonAsync(problemDetails, cancellationToken);

        return true;
    }
}

2. 在Program.cs中注册：

builder.Services.AddExceptionHandler<CustomExceptionHandler>();
builder.Services.AddProblemDetails(); // 可选，用于标准化错误响应

// ...

app.UseExceptionHandler();

总结 #

不要依赖ExceptionFilterAttribute处理Authorization阶段的异常，管道顺序决定了它无法覆盖这个阶段。全局异常处理中间件或IExceptionHandler能覆盖整个请求管道，是更可靠的选择。如果需要复用原异常处理逻辑，建议将核心逻辑抽成公共方法，在多个处理点调用。

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