ASP.NET Core MVC中Windows认证场景下拦截未认证请求的拦截器失效问题咨询

这个问题其实是ASP.NET Core中间件管道顺序和Windows认证默认行为导致的——Windows认证中间件（UseWindowsAuthentication/配合Negotiate的UseAuthentication）默认会在请求进入后续管道前，对未认证请求直接返回401挑战，所以你的自定义拦截器根本没机会执行。要绕过这个行为，有几种可行的方案，取决于你的具体需求：

方案一：允许匿名请求进入管道，通过自定义中间件处理认证逻辑 #

这是最直接的方式，先让未认证请求完整进入管道，再由你的拦截器（自定义中间件）来控制后续流程：

1. 调整认证授权配置：在Program.cs中，不要设置全局强制认证的策略，同时确保Windows认证是可选的（默认就是可选，除非你手动开启了强制）：

builder.Services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
    .AddNegotiate();

// 取消全局默认授权策略，避免自动拦截未认证请求
builder.Services.AddAuthorization(options =>
{
    options.FallbackPolicy = null;
});

2. 添加自定义中间件：把你的拦截逻辑封装成中间件，放在UseAuthentication之后、UseAuthorization之前，这样可以先检查用户身份，再执行自定义逻辑：

public class CustomAuthInterceptorMiddleware
{
    private readonly RequestDelegate _next;

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

    public async Task InvokeAsync(HttpContext context)
    {
        // 检查用户是否已通过Windows认证
        if (!context.User.Identity.IsAuthenticated)
        {
            // 在这里执行你的自定义拦截逻辑：比如记录日志、返回自定义提示
            await context.Response.WriteAsync("未认证请求已被拦截，即将触发Windows认证...");
            
            // 如果需要触发Windows认证挑战，执行这行
            await context.ChallengeAsync(NegotiateDefaults.AuthenticationScheme);
            return;
        }

        // 已认证的请求，继续走后续管道
        await _next(context);
    }
}

3. 注册中间件：在Program.cs的管道配置中添加这个中间件：

app.UseAuthentication();
// 你的自定义拦截器中间件放在这里
app.UseMiddleware<CustomAuthInterceptorMiddleware>();
app.UseAuthorization();
app.MapControllers();

方案二：自定义授权结果处理器，拦截授权失败的请求 #

如果你的应用需要保留全局授权策略（比如全局[Authorize]），可以通过实现IAuthorizationMiddlewareResultHandler来接管授权失败的处理逻辑，替代默认的401响应：

1. 实现自定义处理器：

public class CustomAuthorizationResultHandler : IAuthorizationMiddlewareResultHandler
{
    private readonly AuthorizationMiddlewareResultHandler _defaultHandler = new();

    public async Task HandleAsync(
        RequestDelegate next,
        HttpContext context,
        AuthorizationPolicy policy,
        PolicyAuthorizationResult result)
    {
        // 捕获授权失败的情况（包括未认证）
        if (!result.Succeeded)
        {
            // 执行你的自定义拦截逻辑
            context.Response.StatusCode = StatusCodes.Status401Unauthorized;
            await context.Response.WriteAsync("自定义未认证处理逻辑：请求未通过Windows认证");
            return;
        }

        // 授权成功时，使用默认处理器继续执行
        await _defaultHandler.HandleAsync(next, context, policy, result);
    }
}

2. 注册处理器：在Program.cs中注入这个自定义处理器：

builder.Services.AddSingleton<IAuthorizationMiddlewareResultHandler, CustomAuthorizationResultHandler>();

这样，当Windows认证导致授权失败时，你的自定义逻辑会被触发，而不是直接返回默认的401挑战。

方案三：针对MVC使用自定义ActionFilter（有限场景） #

如果你只需要在MVC控制器/动作级别处理未认证请求，可以使用自定义ActionFilter，但需要配合允许匿名访问——因为如果全局强制认证，请求还是会被Windows认证中间件提前拦截。

1. 创建自定义ActionFilter：

public class CustomAuthActionFilter : IActionFilter
{
    public void OnActionExecuting(ActionExecutingContext context)
    {
        if (!context.HttpContext.User.Identity.IsAuthenticated)
        {
            // 执行自定义拦截逻辑，比如跳转、返回自定义结果
            context.Result = new ContentResult
            {
                Content = "未认证请求已被拦截",
                StatusCode = StatusCodes.Status401Unauthorized
            };
        }
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // 可选：动作执行后的逻辑
    }
}

2. 注册并使用Filter：在Program.cs中添加全局过滤器，或者在控制器/动作上标注[ServiceFilter(typeof(CustomAuthActionFilter))]，同时确保目标控制器/动作允许匿名：

builder.Services.AddScoped<CustomAuthActionFilter>();

builder.Services.AddControllersWithViews(options =>
{
    options.Filters.Add<CustomAuthActionFilter>();
});

然后在控制器上添加[AllowAnonymous]，这样请求才能进入ActionFilter的逻辑：

[AllowAnonymous]
public class HomeController : Controller
{
    // ...
}

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