ASP.NET Core 2.0基于URL的Cookie认证重定向循环问题排查

嘿，我来帮你揪出这个重定向循环的问题！从ASP.NET Core 1.0升级到2.0，认证系统的变动确实容易踩坑，尤其是你这种无登录页、靠URL令牌认证的场景，中间件顺序和配置细节稍有不慎就会陷入循环。下面我从三个核心部分逐一分析可能的问题：

ASP.NET Core 2.0对认证系统做了重构，和1.0的API差异很大，这是最容易出问题的地方：

• 是否用对了认证注册API：1.0的AddIdentity在2.0里被拆分，必须用AddAuthentication指定默认认证方案，再搭配AddCookie配置Cookie参数。如果还在沿用旧的UseIdentity，会导致认证逻辑不生效，用户始终处于未认证状态，反复触发重定向。
• Cookie配置的LoginPath是否坑了你：如果你的AddCookie里设置了LoginPath = "/Account/Login"（默认值），但你根本没有这个登录页，或者这个路径被认证拦截，就会触发“未认证→重定向LoginPath→LoginPath需要认证→再重定向”的死循环。建议要么不设置LoginPath，要么把它指向你的错误页（但必须确保错误页允许匿名访问）。
• 是否给错误页开了匿名权限：如果你的错误页路由（比如/Error/Unauthorized）没有配置允许匿名，重定向过去时会再次触发认证检查，直接导致循环。比如用Razor Pages的话，要在AddRazorPagesOptions里添加options.Conventions.AllowAnonymousToPage("/Error/Unauthorized")。

ASP.NET Core的中间件是按注册顺序执行的，顺序错了直接逻辑混乱：

• 自定义ValidateRequest中间件必须在UseAuthentication之前：你的逻辑是先检查URL令牌，通过后生成Cookie认证用户。如果UseAuthentication先执行，它会先判断用户未认证，然后触发LoginPath重定向，根本轮不到你的令牌检查逻辑，自然会循环。
• UseAuthentication必须在UseMvc之前：2.0里认证中间件要在MVC路由之前执行，这样MVC才能识别已认证的用户，否则控制器/页面的[Authorize]属性会误判用户未认证。

这个中间件是你的核心认证逻辑，最容易出现细节错误：

• 是否正确处理了已认证用户：如果中间件里不管用户有没有认证，都强制检查URL令牌，那已经通过Cookie认证的用户会被再次要求带令牌，否则重定向错误页，导致循环。必须先判断context.User.Identity.IsAuthenticated，如果已认证就直接放行，不用再检查令牌。
• 令牌验证成功后的重定向是否合理：如果验证成功后重定向的URL仍然需要认证，或者重定向的URL又带了无效令牌，会再次进入中间件触发重定向。建议验证成功后，重定向到去掉令牌参数的URL（避免每次请求都带令牌），并且确保这个目标URL是允许已认证用户访问的。
• 是否在重定向后终止了管道：如果重定向后没有return，中间件会继续执行_next(context)，导致后续逻辑又触发认证检查，可能引发循环。

我把正确的配置和中间件逻辑整理出来，你可以对比自己的代码：

ConfigureServices 示例 #

public void ConfigureServices(IServiceCollection services)
{
    // 注册认证服务，指定默认方案为Cookie
    services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
        .AddCookie(options =>
        {
            options.Cookie.Name = "AppAuthCookie";
            options.SlidingExpiration = true;
            options.ExpireTimeSpan = TimeSpan.FromHours(2);
            // 因为无登录页，不设置LoginPath，由自定义中间件处理未认证情况
            options.AccessDeniedPath = "/Error/AccessDenied";
        });

    services.AddMvc()
        .AddRazorPagesOptions(options =>
        {
            // 确保错误页允许匿名访问
            options.Conventions.AllowAnonymousToPage("/Error");
            options.Conventions.AllowAnonymousToPage("/Error/Unauthorized");
        });
}

Configure 示例 #

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    // 自定义令牌验证中间件放在最前面，先处理URL令牌
    app.UseMiddleware<ValidateRequestMiddleware>();

    // 2.0必须用UseAuthentication，替代1.0的UseIdentity
    app.UseAuthentication();

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

ValidateRequestMiddleware 示例 #

public class ValidateRequestMiddleware
{
    private readonly RequestDelegate _next;

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

    public async Task InvokeAsync(HttpContext context)
    {
        // 先判断用户是否已经通过Cookie认证，已认证直接放行
        if (context.User.Identity.IsAuthenticated)
        {
            await _next(context);
            return;
        }

        // 未认证，检查URL中的令牌参数（比如token）
        if (context.Request.Query.TryGetValue("token", out StringValues tokenValue))
        {
            var token = tokenValue.ToString();
            // 替换成你的实际令牌验证逻辑（比如查数据库、验签名）
            bool isTokenValid = IsTokenValid(token);

            if (isTokenValid)
            {
                // 生成认证凭据
                var claims = new List<Claim>
                {
                    new Claim(ClaimTypes.NameIdentifier, "user123"),
                    new Claim(ClaimTypes.Name, "AuthenticatedUser")
                };
                var identity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
                var principal = new ClaimsPrincipal(identity);

                // 生成授权Cookie
                await context.SignInAsync(
                    CookieAuthenticationDefaults.AuthenticationScheme, 
                    principal,
                    new AuthenticationProperties { IsPersistent = true, ExpiresUtc = DateTimeOffset.UtcNow.AddHours(2) });

                // 重定向到去掉token参数的URL，避免重复处理
                var cleanUrl = RemoveTokenFromUrl(context.Request);
                context.Response.Redirect(cleanUrl);
                return;
            }
        }

        // 无有效令牌且未认证，重定向到错误页（确保错误页允许匿名）
        context.Response.Redirect("/Error/Unauthorized");
    }

    private bool IsTokenValid(string token)
    {
        // 示例逻辑：对比预设的有效令牌，替换为你的实际验证逻辑
        return token == "your-valid-secret-token";
    }

    private string RemoveTokenFromUrl(HttpRequest request)
    {
        var queryParams = request.Query.Where(q => q.Key != "token").ToDictionary(q => q.Key, q => q.Value);
        var queryString = QueryString.Create(queryParams);
        return $"{request.PathBase}{request.Path}{queryString}";
    }
}

1. 中间件顺序错误：UseAuthentication在自定义中间件之前执行，导致先触发默认重定向。
2. 错误页未允许匿名：重定向到错误页时再次触发认证检查，形成循环。
3. Cookie配置的LoginPath指向了需要认证的路径：默认的/Account/Login不存在或需要认证，导致反复重定向。
4. 自定义中间件未正确放行已认证用户：不管用户有没有Cookie，都强制要求URL令牌，导致已认证用户也被重定向。

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