Azure NLB负载分发请求时触发AntiForgery异常问题求助

问题根因 #

ASP.NET MVC 的 AntiForgery 令牌生成与解密依赖统一的加密密钥和统一的应用程序标识两个核心要素，你之前的配置未覆盖全部校验规则，因此跨节点请求时令牌解密失败抛出异常。

可行解决方案 #

• 统一全节点机器密钥配置，确保写入生效
  不要仅通过 IIS 图形界面配置机器密钥，直接将生成好的固定密钥写入两个 MVC 节点应用根目录的 web.config 文件中，示例配置如下，确保两个节点的密钥值完全一致，禁用自动生成选项：

  <system.web>
    <machineKey validationKey="你的手动生成的32位以上验证密钥" decryptionKey="你的手动生成的16位以上解密密钥" validation="HMACSHA256" decryption="AES" />
  </system.web>
  

  注意排查子目录下是否存在单独的 web.config 覆盖了根目录的机器密钥配置。

• 统一 AntiForgery 全局配置，规避应用标识差异
  两个节点的 IIS 站点 ID、物理路径不一致会导致 AntiForgery 自动生成的应用标识不匹配，即使密钥一致也会解密失败。在 MVC 项目的 Global.asax.cs 的 Application_Start 方法中添加以下固定配置，覆盖系统自动生成的标识：

  // 统一令牌校验的身份标识字段
  AntiForgeryConfig.UniqueClaimTypeIdentifier = System.Security.Claims.ClaimTypes.Name;
  // 统一令牌Cookie名称
  AntiForgeryConfig.CookieName = "__RequestVerificationToken_Fixed";
  

  编译后将程序集同步部署到两个 MVC 节点。

• 调整共享存储配置，消除权限异常
  不要将共享Session密钥存放在单台VM的共享文件中，极易出现跨节点权限读取失败的问题。可改用 Azure Redis Cache 作为统一的Session和缓存存储，两个节点的Session配置统一指向同一个Redis实例，确保会话状态跨节点一致。同时确认身份验证Cookie的域名、路径、加密配置在两个节点完全相同。

• 临时紧急修复方案
  如果需要快速恢复业务，可先在 MVC 前端的 NLB 中开启会话粘性（客户端亲和性），将单个用户的所有请求固定转发到同一台VM，暂时规避跨节点令牌校验问题，待上述永久配置生效验证通过后再关闭粘性会话，保证负载均衡效果。

验证步骤 #

• 单独访问两台VM的本地站点，确认登录、表单提交功能正常，无AntiForgery异常
• 关闭NLB粘性会话，手动切换用户请求到不同VM，提交表单验证异常是否消除
• 清除客户端所有Cookie后重新登录测试，确认问题完全修复

内容的提问来源于stack exchange，提问作者Abdul Rafay Ali Khan