引发间歇性错误，“未提供所需的防伪令牌或无效。”答案

【问题标题】：Intermittent error thrown, "A required anti-forgery token was not supplied or was invalid."引发间歇性错误，“未提供所需的防伪令牌或无效。”
【发布时间】：2011-02-16 15:03:16
【问题描述】：

我在正常使用过程中偶尔会遇到这个错误，我还没有找到一种方法来阻止它而不删除需要令牌的属性，我宁愿不这样做。

我在自己的测试中遇到了这个错误（但似乎是随机的），我从我的日志中知道实际登录的用户也得到了它。

有谁知道什么会导致 antiforgerytoken 系统崩溃（真正的攻击除外），以及如何在不打开表单安全漏洞的情况下解决这个问题？

谢谢！

【问题讨论】：

不熟悉 MVC2，但如果这种情况很少发生，我会怀疑令牌在用户加载页面和提交表单之间到期。
mark - 我认为真的可以。您应该将其发布为答案，以防万一结果是答案。这不是一个解决方案 - 但它可能是问题所在。我该如何处理即将到期的令牌？需要多长时间才能过期？
在使用 MVC3 和 Firefox 进行测试时，RequestVerificationToken_Lw cookie 在会话结束时过期。我想找到一种方法来强制页面重新加载以刷新 cookie，而不是抛出错误。

标签： asp.net-mvc-2 antiforgerytoken

【解决方案1】：

正如 mpen 在对答案的评论中所说，当用户离开页面超过 20 分钟（默认会话时间）并且令牌过期时，我一直看到这一点。

您可以通过打开浏览器的开发者工具并删除 __RequestVerificationToken 隐藏字段来触发或强制此错误（如果您试图测试捕获它）：

<input name="__RequestVerificationToken" type="hidden" value="AqJL/+e9tGCSCXdurrXDRefVL/TAdOAG9Hjrx0oMPg6sVZY3xv099OSYlH1qI8uZyu4x2xFj9eiNVSH2BGsSfJCQAqzxfQtIKoHXNkkW2FJTkxzsNRkwZo1SJUzYGvcEJ/OJ0AouiUWh98qyIzgN2ZkKP7k=">

【讨论】：

【解决方案2】：

这是我对a similar question 的部分回复：

Machine Key and Cookies：这个问题很难看，很容易发现（导致异常），但不是很直观。验证 cookie 和令牌使用唯一的“机器密钥”进行编码和解码。这意味着如果您有服务器场，或更改您的服务器，您的 cookie 将不再有效。关闭浏览器可以解决问题（因为 cookie 是会话 cookie）。但是，有些人会在后台长时间打开浏览器窗口！
解决方案是在配置文件中设置“机器密钥”。这将告诉 MVC 在所有服务器上使用相同的密钥，确保 cookie 在任何地方都可以解密。

请注意：如果用户保持任何浏览器窗口打开，即使您更改了机器密钥，他们仍将继续收到这些错误消息！他们必须关闭窗口（以清除会话 cookie）才能再次访问您的网站。

【讨论】：

这与我的情况相同，但我已经在 web.config 中使用了机器密钥。我的另一个想法是，用户有一个不会过期的“记住我”功能的 cookie。这个未过期的 cookie 是否可能与防伪令牌/请求验证 cookie 相关联，当该 cookie 过期时，因此与“记住我”cookie 不同？
我只有一台机器，每隔几次尝试就会出现此错误

【解决方案3】：

要确保的一件事是have the same machine key token for all requests。如果您没有这个并且您的应用程序池回收，则使用旧 cookie 的后续 POST 会导致此错误。

另一个原因是当某人的隐私设置过高并因此阻止 cookie 时。例如，在 Internet Explorer 的隐私选项卡中，如果设置设置为高或阻止所有 Cookie，您将收到此错误。

【讨论】：

在 Firefox 中遇到问题。无法找出原因 - 结果是所有 cookie 都因某种原因被禁用。我的理论是我在 Firebug 中禁用了它们（然后我将其卸载），并且这个设置仍然存在。

【解决方案4】：

不确定这是否会有所帮助，但我发现在使用 Internet Explorer 时，只要子域内有下划线“_”，我就会收到此错误...但在 Firefox 上不会。

仍在寻找解决方案或推理。

【讨论】：

谢谢 ioSamurai！我从来没有想过下划线是罪魁祸首。

【解决方案5】：

阅读此处有关限制的部分

prevent cross site request forgery

【讨论】：

不，一切设置正确。该错误很少发生，每周一次左右，偶尔在繁重的测试期间发生。
我在那里看到的唯一与我实现的不同的想法是，他们表明：而我通常实现这个：因为这是一个表格帖子，我认为这无关紧要，我仍然不不。但在这一点上，我会更改任何内容以使其正常工作。
stackoverflow 应该允许 cmets 中的代码块 - 无论如何，关键是我在表格的末尾而不是在开头有令牌字段。现在是开始。

【解决方案6】：

确保您的 ~/Web.config 有一个部分，并且您在该部分中设置密钥。反 XSRF 系统要求它存在。

【讨论】：

我在上次尝试解决此问题时已经这样做了。它没有帮助，但理论上这是一个必要的步骤。谢谢
如果您可以访问您机器的事件日志，您是否可以检查它是否有与反 XSRF 无效异常几乎同时发生的任何条目？例如，这些是否会在 AppDomain 重新启动等之后立即发生？
我会研究一下这个 Levi，另一个有趣的想法。不确定此时是会话到期还是 appdomain 重新启动 - 这两个建议似乎都是合理的。再次感谢！