页面持续 20+ 时视图状态 MAC 验证失败分钟
如果您在我们服务器上托管的网站之一上打开网页，等待 20 分钟，然后提交表单，则会出现视图状态 MAC 验证失败。 错误。
造成这种情况的可能原因有哪些？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
如果您在我们服务器上托管的网站之一上打开网页，等待 20 分钟，然后提交表单，则会出现视图状态 MAC 验证失败。 错误。
造成这种情况的可能原因有哪些？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（5）
发生这种情况的原因有多种：
自动生成的计算机密钥：
如果您的应用程序池的默认空闲超时为 20 分钟，并且您使用自动生成的验证和解密密钥，则每次池启动它将生成一组新的密钥。这会使浏览器的加密视图状态无效。您还会发现持久票证的表单身份验证票证也将变得无效。
为了克服这个问题，请将这些键设置为固定值：
您需要将
向下滚动到“部分”关于“网络场部署注意事项”和生成加密随机密钥。
如果您正在运行负载平衡的网络场，您还需要将每个服务器的计算机密钥设置为完全相同的值。
表单
action值不正确 (3.5SP1)：还有一种情况（3.5SP1 后），如果您设置 ASP 的
action属性。 NET 表单发送回的页面以外的其他内容，并且您没有使用跨页面回发，那么您将收到此错误。但你马上就会看到这个：计时/长时间运行页面：
对于需要很长时间呈现的页面，还有一种边缘情况，即页面部分呈现并发生回发:
There's a few reasons this can happen:
Auto-Generated Machine Keys:
If your application pools have the default idle timeout of 20 minutes AND you're using auto-generated validation and decryption keys then each time the pool starts it will generate a new set of keys. This invalidates the browser's encrypted viewstate. You'll also find that forms authentication tickets for persistent tickets will also become invalid.
To overcome this set these keys to fixed values in:
You need to add the
<machineKey>configuration element to the<system.web>section. There's a pretty good article here that explains how to do this:Scroll down to the section on "Web Farm Deployment Considerations" and Generate Cryptographically Random Keys.
If you're running a load balanced web farm you also need to set each server's machine key to exactly the same value.
Incorrect form
actionvalue (3.5SP1):There's also a case (post 3.5SP1) where if you set the
actionattribute of your ASP.NET form to something other than the page being posted back to and you're not using crosspage postbacks then you will get this error. But you'd see this right away:Timing/Long Running Pages:
There's also an edge case for pages that take a long time to render where if the page is partially rendered and a postback occurs:
我们花了一段时间才找到这个问题的答案，因为我被告知我正在比较的另一台 IIS7 服务器是由同一个人以相同的方式设置的。
事实证明，收到此错误的网站的服务器是使用 Plesk 设置的，而其他服务器则没有。
看来 Plesk 将应用程序池的空闲超时设置为 5 分钟，这就是导致此错误的原因。
要更改此设置，请执行以下操作：
It's taken us a while to find the answer to this as I had been informed that another IIS7 server I was comparing it to had been setup in the same way, by the same person.
It turns out the server with the websites which were receiving this error had been setup using Plesk, whereas the other server had not been.
It seems Plesk sets the Idle-Timeout to 5 minutes on the application pools, which is what was causing this error.
To change this do the following:
对我来说，这解决了问题：
我在应用程序池中设置了
LoadUserProfile = True以使 HKCU 注册表配置单元可供应用程序使用。注意：这与 IIS 7.0+ 兼容
For me, this solved the problem:
I've set
LoadUserProfile = Truein the application pool to make HKCU registry hive be available to the application.Note: This is compatible with IIS 7.0+
我遇到了这个问题，场景是托管一个非常基本的 ASP.Net 应用程序的单个 Web 服务器。经过一番努力后，我找到了这篇文章，这帮助我理解问题是工作进程被回收。
我发现这非常严酷，因为这是应用程序可能面临的场景，而这样的核心错误会阻止您正确处理它。据我所知，这是因为处理此密钥的默认配置将使用 machine.config ，该配置声明密钥是根据应用程序自动生成和隔离的。我认为在这种情况下 ASP.Net 是一个临时密钥并将其存储在工作进程级别，当该工作进程消失时，问题就会出现并且无法处理。
配置机器密钥的替代方案可以解决问题，显然最好将其设置在
web.config文件上，而不是整个machine.config上，以使其保持在最低粒度等级。另一种选择是禁用视图状态 MAC 检查，同样通过 web.config。这取决于应用程序的安全级别以及视图状态被篡改的风险。
最好的选择是避免在 MVC 应用程序中使用视图状态。
I ran into this problem, and the scenario was a single web server hosting a very basic ASP.Net application. After struggling a lot I found this post, and that helped me to understand that the problem was the worker process getting recycled.
I find this quite harsh, as it's a scenario that an application might face and such a core error prevents you to handle it properly. As far I could see, this is originated because the default configuration for handling this keys will use the
machine.configthat states that keys are automatically generated and isolated per application. I think in this cases ASP.Net a temporary key and store it at the worker process level, and when that worker process is gone the issue arises and can't be handled.The alternative of configuring the machine key solves the problem, clearly is better to set it on the
web.configfile rather the wholemachine.configto keep it at the lowest granularity level.Another option is to disable the view state MAC check, also through
web.config. It will depend on the security level of your application and the risk of having the view state tampered with.And the best option is to avoid using view state with a MVC application.
视图状态 MAC 验证失败。如果此应用程序由 Web Farm 或集群托管，请确保配置指定相同的validationKey 和验证算法。 AutoGenerate 不能在集群中使用
我发现，有一个
标记在我的母版页的标题部分，我在最后一条领带和发布之前添加了该标记。此标记指定页面上所有链接的默认 URL 和默认目标。这是这次故障的主要原因。
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that configuration specifies the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster
As I found out, there was a
<base ....tag in header part of my master page, that I added in last tie and before publishing. This tag specify a default URL and a default target for all links on a page. This was the main cause of the fault, this time.