我该如何解决我的ASP.Net MVC应用程序的IISRESET后发生的AntiForgeryToken异常？ [英] How do I solve an AntiForgeryToken exception that occurs after an iisreset in my ASP.Net MVC app?

问题描述

我有问题的AntiForgeryToken在ASP.Net MVC。如果我做一个IISRESET我的Web服务器上，用户继续使用他们的会话，他们得到反弹到登录页面。不可怕但随后的防伪标记吹起来，把身上会被吹走cookie的浏览器上的唯一途径。

随着第1版的测试版以前读的cookie回了我，所以我使用的要求验证令牌之前擦洗它，但是当它被释放被固定的时候出问题。

现在，我想我会回滚到我的code是固定的测试问题，但我不禁觉得我失去了一些东西。有没有一个简单的解决方案，到底我应该只是放弃他们的助手，并从头开始创建一个新的？我得到了很多的问题是，它的捆绑如此之深成老ASP.Net管道，并试图杂牌成做一些它是不是真的为了做的感觉。

我在源$ C ​​$ C的ASP.Net MVC 2 RC一看，它看起来并不像code有太大的变化等等，而我还没有尝试过，我不知道认为有任何答案的。

下面是异常的堆栈跟踪的相关部分。

编辑：我才意识到我没有提到这只是试图插入的GET请求令牌。这不是当你做一个POST开球时出现的验证。

  System.Web.Mvc.HttpAntiForgeryException：一个必需的防伪标记不
供应或无效。
---＆GT; System.Web.HttpException：视图状态MAC的验证失败。如果这
应用程序是由Web场或群集承载，确保＆LT;将machineKey＆GT;
配置指定了相同的validationKey和验证算法。
自动生成不能在集群中使用。
---＆GT; System.Web.UI.ViewStateException：无效的视图状态。
  客户端IP：127.0.0.1
  端口：4991
  用户代理：擦洗
  ViewState的：擦洗
  引用站点：胡说
  路径：/ oursite /帐号/登录
---＆GT; System.Security.Cryptography.CryptographicException：填充是无效的
不能除去。
在System.Security.Cryptography.RijndaelManagedTransform.DecryptData（字节[] INPUTBUFFER，的Int32 inputOffset，的Int32 inputCount，字节[]放大器; OUTPUTBUFFER，的Int32 outputOffset，PaddingMode paddingMode，布尔fLast）
在System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock（字节[] INPUTBUFFER，的Int32 inputOffset，的Int32 inputCount）
在System.Security.Cryptography.CryptoStream.FlushFinalBlock（）
在System.Web.Configuration.MachineKeySection.EncryptOrDecryptData（布尔fEncrypt，字节[] buf中，字节]修饰符，的Int32开始的Int32长度，IVType ivType，布尔useValidationSymAlgo）
在System.Web.UI.ObjectStateFormatter.Deserialize（字符串inputString）
---内部异常堆栈跟踪的结尾---
---内部异常堆栈跟踪的结尾---
在System.Web.UI.ViewStateException.ThrowError（异常内，字符串persistedState，字符串errorPageMes​​sage，布尔macValidationError）
在System.Web.UI.ViewStateException.ThrowMacValidationError（异常内，串persistedState）
在System.Web.UI.ObjectStateFormatter.Deserialize（字符串inputString）
在System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize（字符串serializedState）
在System.Web.Mvc.AntiForgeryDataSerializer.Deserialize（字符串serializedToken）
---内部异常堆栈跟踪的结尾---
在System.Web.Mvc.AntiForgeryDataSerializer.Deserialize（字符串serializedToken）
在System.Web.Mvc.HtmlHelper.GetAntiForgeryTokenAndSetCookie（字符串盐，字符串域，字符串路径）
在System.Web.Mvc.HtmlHelper.AntiForgeryToken（字符串盐，字符串域，字符串路径）
 

解决方案

如果您的 machineKey中设置为自动生成，那么您的验证令牌等将无法生存重新启动应用程序 - 启动时ASP.NET将生成一个新的密钥，然后将不能够正确解密的标记。

如果您在此看到了很多，我建议：

1. 在配置静态的machineKey（你应该能够在应用层面做到这一点），请参见如何于：配置的machineKey了解更多信息
2. 尝试不执行IIS复位时，该网站正在使用 ¹

¹ 做到这一点的最好办法是通过具有loadbalanced的应用程序，它会要求你设置一个静态的machineKey。另一种选择是通过将一个名为 app_offline.htm 在站点的根目录文件，该文件将采取现场离线并显示你的信息采取现场下来 - 至少在用户会想到事情会出错。

I’m having problems with the AntiForgeryToken in ASP.Net MVC. If I do an iisreset on my web server and a user continues with their session they get bounced to a login page. Not terrible but then the AntiForgery token blows up and the only way to get going again is to blow away the cookie on the browser.

With the beta version of version 1 it used to go wrong when reading the cookie back in for me so I used to scrub it before asking for a validation token but that was fixed when it was released.

For now I think I’ll roll back to my code that fixed the beta problem but I can’t help but think I’m missing something. Is there a simpler solution, heck should I just drop their helper and create a new one from scratch? I get the feeling that a lot of the problem is the fact that it’s tied so deeply into the old ASP.Net pipeline and is trying to kludge it into doing something it wasn’t really designed to do.

I had a look in the source code for the ASP.Net MVC 2 RC and it doesn't look like the code has changed much so while I haven't tried it, I don't think there are any answers there.

Here is the relevant part of the stack trace of the exception.

Edit: I just realised I didn't mention that this is just trying to insert the token on the GET request. This isn't the validation that occurs when you do a POST kicking off.

System.Web.Mvc.HttpAntiForgeryException: A required anti-forgery token was not
supplied or was invalid.
---> System.Web.HttpException: Validation of viewstate MAC failed. If this 
application is hosted by a Web Farm or cluster, ensure that <machineKey> 
configuration specifies the same validationKey and validation algorithm. 
AutoGenerate cannot be used in a cluster.
---> System.Web.UI.ViewStateException: Invalid viewstate. 
  Client IP: 127.0.0.1
  Port: 4991
  User-Agent: scrubbed
  ViewState: scrubbed
  Referer: blah
  Path: /oursite/Account/Login
---> System.Security.Cryptography.CryptographicException: Padding is invalid and
cannot be removed.
at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
--- End of inner exception stack trace ---
--- End of inner exception stack trace ---
at System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError)
at System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState)
at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
at System.Web.Mvc.AntiForgeryDataSerializer.Deserialize(String serializedToken)
--- End of inner exception stack trace ---
at System.Web.Mvc.AntiForgeryDataSerializer.Deserialize(String serializedToken)
at System.Web.Mvc.HtmlHelper.GetAntiForgeryTokenAndSetCookie(String salt, String domain, String path)
at System.Web.Mvc.HtmlHelper.AntiForgeryToken(String salt, String domain, String path)

解决方案

If your MachineKey is set to AutoGenerate, then your verification tokens, etc won't survive an application restart - ASP.NET will generate a new key when it starts up, and then won't be able to decrypt the tokens correctly.

If you are seeing this a lot, I'd suggest:

1. Configuring a static MachineKey (you should be able to do this at the application level), see "How to: Configure a MachineKey" for more information
2. Try not to perform IIS Resets when the site is being used¹

¹ The best way to do this is by having a loadbalanced application, which will require you to set a static MachineKey. Another option is to take the site down by placing a file named app_offline.htm in the root of the site, which will take the site offline and display your message - at least the users will expect things to go wrong.

这篇关于我该如何解决我的ASP.Net MVC应用程序的IISRESET后发生的AntiForgeryToken异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！