Web Farms and ASP.NET ViewState
If you deploy ASP.NET websites to a web farm, you may run into this perplexing System.Web.HttpException:
The viewstate is invalid for this page and might be corrupted
If you’ve installed ASP.NET 1.1 service pack 1, you may also get a much more helpful exception from System.Web.UI.LosFormatter.Deserialize:
Authentication of viewstate failed. 1) If this is a cluster, edit configuration so all servers use the same validationKey and validation algorithm. AutoGenerate cannot be used in a cluster. 2) Viewstate can only be posted back to the same page. 3) The viewstate for this page might be corrupted.
So clearly there’s a problem with the ASP.NET viewstate.
As pointed out in Rich Crane’s blog entry, ASP.NET ViewState is tied to the particular server it came from by default – even though the documentation says it isn’t. So when ViewState generated on server A is POST-ed back to server B, you’ll get this exception. Somewhere in the pipeline, the viewstate is salted with a unique, autogenerated machine key from the originating server’s machine.config file:
<!-- validation="[SHA1|MD5|3DES]" --> <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>
This is done to prevent users from somehow tampering with the ViewState. Any change to the ViewState data on the client will be detected. But this has a side effect: it also prevents multiple servers from processing the same ViewState. One solution is to force every server in your farm to use the same key – generate a hex encoded 64-bit or 128-bit <machineKey> and put that in each server’s machine.config (note that this key is bogus and shown only for illustration; don’t use it):
<!-- validation="[SHA1|MD5|3DES]" --> <machineKey validation="SHA1" validationKey="F3690E7A3143C185A6A8B4D81FD55DD7A69EEAA3B32A6AE813ECEEC" />
Or – and I think this is the easier approach – you can disable the keying of viewstate to a particular server using a simple page directive at the top of your .aspx pages:
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="MyPage.aspx.vb" Inherits="MyAssembly.MyPage" enableViewStateMac="False" %>
Alternately, you can modify the pages element in Web.config:
<system.web> <pages enableViewStateMac="false" /> </system.web>
Either way, works great. Who needs all that stupid security anyway?
