Since I can’t post a link:
"Validation of viewstate MAC failed / The state information is invalid for this page & might be corrupted…
OR
Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey> configuration specifies the same validationKey & validation algorithm. AutoGenerate cannot be used in a cluster.
You’d be astonished if you’d get this weird error all of a sudden on a working ASP.Net web application, I was
This error infact is a bug in the ASP.Net Framework which has troubled most of the web development masses !
Viewstate usually represents the state of the page when it was last successfully processed / executed on the server… The contents of the page are stored in a container & moved to & from the server on each request. By default, ASP.NET validates the contents of viewstate to ensure that it has not been tampered. If this validation test fails, an invalid viewstate exception is thrown.
This common errors results specifically from an ASP.net 2.0 web application when using forms or rather a postback method or from the feature called Event Validation… When you postback before the EventValidation field has been rendered, this will throw the exception. If EventValidation is enabled (it is by default), but ASP.net doesn’t see the hidden field when you postback, you also get the exception… If you submit a form before it has been entirely rendered, then chances are the EventValidation field has not yet been rendered, & thus ASP.net cannot validate your click & throws the error. This is a security feature that ensures that postback actions only come from events allowed & created by the server to help prevent spoofed postbacks… This feature is implemented by having controls register valid events when they render. The end result is that at the bottom of your rendered <form> tag, you’ll see something like this:
Quote:
<input type=“hidden” name=“__EVENTVALIDATION” id=“__EVENTVALIDATION” value=“AEBnx7v…tS” />
When a postback occurs, ASP.net uses the values stored in this hidden field to ensure that the button you clicked invokes a valid event… If it’s not valid, you get the exception that you’ve been seeing all along…
There are a few ways to avoid MAC mismatch mishaps:
Don’t use the ViewState if you don’t need to. Not only will it avoid the whole MAC issue, but your pages will run faster to boot…
Turn off MAC generation by setting enableViewStateMac=false in the page or web.config… This isn’t recommended, since the MAC helps prevent people from tampering with your viewstate data. But if tampering with viewstate data isn’t a concern (& it may not be for some applications where there’s no risk of fraud or security breaches), you can turn it off.
Prevent your application pool from restarting by disabling the auto recycle & idle timeout settings in the application pool. This isn’t a 100% guarantee that the pool won’t restart, but it does help…
Hard-code the MAC validation key so that it’s always the same. I recommend this approach for web farms &/or if your application pool keep restarting for whatever reason (overzealous admins, memory leaks, etc). The biggest risk is now your key is hard-coded in a file, so you need to make sure your server is secure so that people don’t get that key (otherwise they could hack your viewstate). You can hardcode the key in the <machineKey> tag in the machine.config or web.config, like this:
Quote:
<!-- validation=“[SHA1|MD5|3DES]” –>
<machineKey validation=“SHA1” validationKey=“NXBXUKMF19UN5SCJX1SF5XXTR0MK4EYAMBJ 5GYRPAGMBAAGGADANBGKQHKIG9W0B” />
If you’re using ASP.NET 2.0, your machineKey tag should also have the decryption attribute:
Quote:
<machineKey
validationKey=“NXBXUKMF19UN5SCJX1SF5XXTR0MK4EYAMBJ 5GYRPAGMBAAGGADANBGKQHKIG9W0B”
decryptionKey=“RNNWWNSU7WJBAMQ8R4XAOMIH7SPRZPF7LHI MRHWVIF2AB7NA6AII7OXYE2JSX7ZM”
validation=“SHA1”
decryption=“AES”
/>
Server Farms or Server Clusters: Applications running in a server cluster must have all the machineKey configurations set to the same validationKey. The default AutoGenerate key cannot be used in a cluster environment. The registry keys responsible for auto generation of these values are listed here:
Quote:
HKEY_LOCAL_MACHINE\Software\Microsoft\ASP.NET
HKEY_CURRENT_USER\Software\Microsoft\ASP.NET
When the machineKey is set to AutoGenerate, the key information is stored in the HKEY_CURRENT_USER hive for the account running the process. For W2k3 servers, this is the Network Service account… Otherwise, the account is ASP.NET machine account. When the process launches, ASP.NET will use the HKEY_CURRENT_USER registry key if it is available. If this key is not available, the HKEY_LOCAL_MACHINE key will be used. If neither registry key exists, the process creates the key in the HKEY_LOCAL_MACHINE hive. If these conditions fail, the process creates a brand new set of keys…
When the application pool is running under a user account, the above keys are not generated leading to an intermittent invalid viewstate error.
The workaround is to use a specific key in the machine.config to prevent automatic key generation on each process start. The key must be exactly 128 bits made up of random characters & inserted into the configuration file on each web server experiencing the problem.
Form Posts: Viewstate can only be posted back to the same page. Attempting to post an aspx form to another page will fail with a viewstate invalid exception. This behavior is by design.
The remedy involves into disabling the Machine Authentication Check, unless you implement a back up authentication mechanism, you should refrain from this approach. Machine Authentication Checks are important in reducing the attack surface of ASP.NET applications as described above.
You have to be aware of the security implications. Alternatively, just never post back before the form has finished rendering…
Adjust the settings on the application pools so that recycling is less likely to occur at peak periods.
Use a specific key in the machine.config to prevent automatic key generation on each process start.
Only post to the same ASPX page.
You can disable the UI until the form has rendered, it can be done in the following way:
Quote:
<%@ Page Language=“vb” AutoEventWireup=“false” Codebehind=“Text.aspx.vb” Inherits=“TestAssembly.TestPage” enableViewStateMac=“False” %>
Or through the web.config in the following manner:
Quote:
<system.web>
<pages enableViewStateMac=“false” />
</system.web>
You’d also want to try including the following in the header of your .aspx pages to overcome the error:
Quote:
<meta http-equiv=“Page-Enter” content=“RevealTrans(Duration=0,Transition=0)” />
Including this tag in the header of your page disables the use of the page until it has completely downloaded to the user’s browser. This also reduces the “flicker” effect that occurs on postbacks…
Unfortunately there’s no “perfect” solution for this error as yet. Disabling the enableViewStateMac is ok but in addition to this solution you must store the ViewState somewhere else i.e. Session, Cache so that it won’t get transmitted to the browser & get played around.
The best way is to not use critical information in viewstate or not use components which use viewstate for saving their data. If you need dynamic queries build them every time page refreshes to gain maximum security. Use StateServer or Sessions to store the session/cached data & to maintain sessions on a server farm…
Best luck… "