.NET 6 Service Worker调用带默认认证的ASP.NET Core MVC API问题

ASP.NET Core Individual Accounts默认的登录端点（Account/Login）只接受表单格式的请求，且必须携带CSRF防伪造令牌，这是你之前用JSON传参返回400的核心原因。以下是正确的登录流程：

步骤1：获取登录页面的CSRF令牌 #

默认登录页面会生成一个隐藏的__RequestVerificationToken字段，必须在登录请求中携带该值才能通过验证。你需要先发送GET请求到登录页面，从HTML中提取这个令牌。

步骤2：构造表单格式的登录请求 #

用FormUrlEncodedContent构造请求体，包含登录所需的必填字段（Email/Username、Password、RememberMe、CSRF令牌），并设置正确的Content-Type头。

完整代码示例（.NET 6 Service Worker中使用） #

using System.Net.Http.Headers;
using System.Text.RegularExpressions;

// 初始化HttpClient（建议在Service Worker中注册为单例）
var httpClient = new HttpClient();
httpClient.BaseAddress = new Uri("https://your-api-domain/");

// 1. 获取登录页面并提取CSRF令牌
var loginPageResp = await httpClient.GetAsync("Account/Login");
loginPageResp.EnsureSuccessStatusCode();
var loginPageHtml = await loginPageResp.Content.ReadAsStringAsync();

var csrfMatch = Regex.Match(loginPageHtml, @"<input name=""__RequestVerificationToken"" type=""hidden"" value=""([^""]+)"" />");
if (!csrfMatch.Success)
{
    throw new InvalidOperationException("无法提取登录页面的CSRF令牌");
}
var csrfToken = csrfMatch.Groups[1].Value;

// 2. 构造登录表单数据
var loginForm = new Dictionary<string, string>
{
    ["Email"] = "service-account@your-domain.com", // 替换为有权限的账号
    ["Password"] = "your-secure-password",
    ["RememberMe"] = "false",
    ["__RequestVerificationToken"] = csrfToken
};

var loginContent = new FormUrlEncodedContent(loginForm);
loginContent.Headers.ContentType = new MediaTypeHeaderValue("application/x-www-form-urlencoded");

// 3. 发送登录请求，HttpClient会自动保存会话Cookie
var loginResp = await httpClient.PostAsync("Account/Login", loginContent);
loginResp.EnsureSuccessStatusCode();

// 4. 调用PaymentController的认证接口
var failedPaymentsResp = await httpClient.GetAsync("Payment/FailedPayments");
failedPaymentsResp.EnsureSuccessStatusCode();
// 处理返回的失败支付数据
var failedPayments = await failedPaymentsResp.Content.ReadAsStringAsync();

优先尝试现有方案 #

如果上述流程能正常运行，完全不需要修改原API。这个方案严格遵循原项目的认证逻辑，适合你的Service Worker定时任务场景。

建议修改API的场景 #

如果遇到以下问题，再考虑提出修改API的需求：

• 原项目登录页面结构频繁变动，导致CSRF令牌的正则提取逻辑经常失效，维护成本过高
• 原项目启用了额外安全机制（如登录验证码、IP白名单），无法通过自动化方式完成登录
• 会话Cookie过期频繁，需要频繁重新登录，影响定时任务稳定性
• 从安全和架构角度，服务端之间的调用更适合使用API密钥或JWT令牌，而非Cookie认证（Cookie更适合浏览器端会话）

若要修改API，建议的方案：

• 新增一个专门用于服务端调用的认证端点，支持API密钥验证
• 修改PaymentController的认证方式，允许同时支持Cookie和JWT/API密钥认证

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