Viewstate is the process used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks e.g when a page post's back (such as after a submit button or asp.net server control is clicked), when the page reappears the various form fields still contain their data. This is because ASP .NET maintains the page (or view) state via the use of a hidden field placed on each page with a
DotNetNuke has viewstate enabled by default, so module developers should take care to not use unnecessary server controls, or to disable viewstate at the control level, to ensure viewstate does not get too large and impact performance.
Issues with Viewstate
Viewstate issues can occur if a site is hosting in a webfarm and each webserver does not share the same viewstate keys (i.e. the machinekey validationkey and decryptionkey values). If this is the case an error such as the following can occur:
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
By default DotNetNuke does not use autogenerate keys, so to rectify this the machinekey node from web.config simply needs to match on other machines. Note, you will still need to ensure your webfarm is using the relevant Caching Providers
This message can occur for a few other reasons:
- DotNetNuke implements cross-site request forgery protection via the viewstatekey setting in asp.net. This means that any postbacks to a site are checked to ensure they come from that site, and are not "cross" posted from another website. As these checks use the viewstate key's, if the application recycles and the values change this can cause the error. This most commonly manifests when a user has left the site idle for a period of time greater than the app recycle (by default 20 minutes), or an operation on the site has caused an app recycle (e.g. installing a module, or the hosting provider automating a recycle). This protection was added in 5.5.0 so if your site has started to see these more regularly this is the likely case and not something to worry about. Unfortunately as the failed viewstate is caught early in the asp.net event cycle, DotNetNuke cannot catch and distinguish it from other viewstate events.
- If a postback event occurs whilst a slow-loading page is still loading this can happen e.g. if a page containing a gridview is only partially loading, clicking a sort header can cause this. This is caused as the viewstate value was added as the final value in the page in earlier versions of .net (1.0-3.5). Upgrading to .net 3.5sp1 or higher changes this so the viewstate is loaded first, maximising the chances it is fully loaded when a postback event occurs. It's also recommended that page sizes are kept as small as possible.
- On rare occasions the viewstate issues are isolated to a internet explorer browser. As IE can cache webpages, a cached copy of a page may contain an "old" viewstate key. This is not a correct behaviour in the browser, but typically it can be resolved by asking the client to press CTRL+F5 to force a fresh load. Alternatively, clients can set their IE browser to pull fresh copies of the page by going to tools->internet options, clicking settings and selecting "Every Time I visit the web page"
- Attempts to use website's as spam relays can cause this issue, see here for more.
- Microsoft lists a number of other possibilities
Note: the 6.0.1 release added some code to catch some of the harmless instances of this and supress the error messages.Further references
Viewstate encryption is a best practice and a good way to provide an additional level of security (a defence in depth
approach). This was enabled as the default for the 5.6.1 release, but is a recommended practice for all versions, to make this change add the viewStateEncryptionMode attribute to the pages node in web.config and set it to Always i.e.
<pages validateRequest="false" enableViewStateMac="true" enableEventValidation="false" viewStateEncryptionMode="Always">