.NET Core 2.0+IdentityServer4中ValidateAntiForgeryToken致更新异常

首先，我得先明确几个关键点：你遇到的更新失效，大概率是AntiForgeryToken验证不通过，或者验证通过后，工作单元/仓储的上下文状态出现了问题。结合你用的.NET Core 2.0、EF Core无延迟加载、工作单元+独立仓储的架构，我整理了几个排查和解决方向：

1. 先确认AntiForgeryToken的传递是否正确 #

ValidateAntiForgeryToken属性会拦截没有携带有效令牌的POST/PUT请求，直接返回400错误，看起来就像“更新失效”。你需要确保：

• 如果是表单提交：页面里必须包含@Html.AntiForgeryToken()（Razor视图），或者<input type="hidden" name="__RequestVerificationToken" value="..." />，且表单的method是POST。
• 如果是AJAX请求：需要在请求头里添加RequestVerificationToken，值从页面的隐藏字段中获取，比如：

  var token = $('input[name="__RequestVerificationToken"]').val();
  $.ajax({
    type: "POST",
    url: "/Clients/Update",
    headers: {
      "RequestVerificationToken": token
    },
    data: clientData,
    success: function(result) { ... }
  });
  

• 另外，.NET Core 2.0中，默认的AntiForgery配置可能会关联Cookie的SameSite属性，如果你的请求跨域或者Cookie策略有调整，也可能导致验证失败。可以在Startup.cs里临时放宽测试：

  services.AddAntiforgery(options =>
  {
      options.Cookie.SameSite = SameSiteMode.None;
      options.Cookie.SecurePolicy = CookieSecurePolicy.None;
  });
  

  测试通过后再调整为符合安全要求的配置。

2. 排查工作单元与仓储的上下文生命周期问题 #

因为你用了独立仓储+工作单元，且EF Core没有延迟加载，很容易出现上下文跟踪冲突或者关联数据没有正确加载/附加的情况，而AntiForgeryToken验证通过后，请求进入业务逻辑，但因为EF的状态问题导致更新没写入数据库：

• 确保工作单元的DbContext是请求生命周期（Scoped）的，所有仓储都共享同一个上下文实例。如果每个仓储都自己创建DbContext，会导致实体处于不同的上下文，更新时无法跟踪。
  比如在Startup里注册：

  services.AddDbContext<AppDbContext>(options => 
      options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
  services.AddScoped<IUnitOfWork, UnitOfWork>();
  services.AddScoped<IClientRepository, ClientRepository>();
  services.AddScoped<IClientScopeRepository, ClientScopeRepository>();
  

• 当更新Client及其关联的ClientScopes/Secrets时，需要手动将关联实体附加到上下文，并设置正确的状态。因为没有延迟加载，你需要在查询Client时Include关联数据：

  public async Task<Client> GetClientWithDetails(int clientId)
  {
      return await _context.Clients
          .Include(c => c.ClientScopes)
          .Include(c => c.ClientSecrets)
          .FirstOrDefaultAsync(c => c.Id == clientId);
  }
  

  然后在更新时，对新增/修改/删除的ClientScopes，手动设置EntityState：

  foreach (var scope in updatedClient.ClientScopes)
  {
      if (scope.Id == 0)
      {
          _context.ClientScopes.Add(scope);
      }
      else
      {
          _context.Entry(scope).State = EntityState.Modified;
      }
  }
  // 删除不在更新列表中的旧Scope
  var existingScopes = await _context.ClientScopes.Where(s => s.ClientId == clientId).ToListAsync();
  foreach (var existing in existingScopes)
  {
      if (!updatedClient.ClientScopes.Any(s => s.Id == existing.Id))
      {
          _context.ClientScopes.Remove(existing);
      }
  }
  

• 你提到用Func<>实现关联数据的筛选查询，要确保这个Func是在DbContext的上下文中执行的，而不是在内存中。比如不要先ToList()再筛选，那样会导致后续的更新无法跟踪实体。

3. 检查Action的参数绑定与模型验证 #

有时候更新失效不是AntiForgery的问题，而是模型绑定失败，导致Action接收的Client对象是null或者不完整，而ValidateAntiForgeryToken只是刚好在这个Action上，让你误以为是它的问题。可以在Action里加ModelState.IsValid的检查：

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> UpdateClient(ClientViewModel model)
{
    if (!ModelState.IsValid)
    {
        // 返回错误信息，检查模型绑定哪里出了问题
        return View(model);
    }
    // 后续的更新逻辑
    await _unitOfWork.ClientRepository.Update(model.ToClient());
    await _unitOfWork.SaveChangesAsync();
    return RedirectToAction("Index");
}

如果ModelState无效，把错误信息打印出来，看看是不是关联数据（比如ClientScopes）没有正确绑定。

4. 启用日志排查验证细节 #

在.NET Core 2.0中，你可以启用Antiforgery的日志，查看验证失败的具体原因。在appsettings.json里添加：

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.Antiforgery": "Debug"
    }
  }
}

然后查看日志，会显示验证失败的具体原因（比如令牌不匹配、Cookie缺失等），这能帮你快速定位问题。

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