[Excerpt] view MAC verification fails Validation of ViewState MAC Failed

Original Address:  http://hi.baidu.com/harryhdk/blog/item/0f1bc134591becb0d1a2d364.html

View MAC verification fails Validation of ViewState MAC Failed

Today encountered an error while debugging Atlas:

View MAC verification fails. If the referenced field or cluster carried by the network, make sure the <machineKey> configuration specifies the same validationKey and authentication algorithms. You can not use cluster AutoGenerate

Error occurred environment:

ASP.NET 2.0, using the Atlas UpdatePanel, UpdatePanel in dynamic load user controls to achieve the effect of dynamically update the page. There is a user control using the GridView. When the dynamic switch pages, the above error.

problem analysis:

After some searching, found the following article:

http://aspadvice.com/blogs/joteke/archive/2006/02/02/15011.aspx

http://forums.asp.net/1173230/ShowPost.aspx

After the analysis found the root of the problem. First, the article mentioned that if the GridView, and specifies DataKeyNames property, then for security reasons (because the primary key field represents DataKeyNames specified data, and the primary key value needs to be saved to the client in view state, If the user tampering primary key values, cause security issues), GridView will be asked to encrypt view state. To do this will automatically add the page Form </ forms> before a <input type = "hidden" name = "__ VIEWSTATEENCRYPTED" id = "__ VIEWSTATEENCRYPTED" value = "" />.

However, Atlas of placing in UpdatePanel <form> </ form> inside, i.e. before the </ form>. This means adding a hidden input control is not to be placed in the UpdatePanel, but placed between the UpdatePanel and </ form>.

When the update UpdatePanel, UpdatePanel internal controls are submitted to the server for processing (Patrial Rendering), and the entire page has not been submitted. That hidden input control is not submitted along with. So the server does not know ViewState submit is encrypted, and therefore, the MAC validation error.

Solution:

By adding the Web.config inside

<pages enableEventValidation="false" viewStateEncryptionMode ="Never" />

You can solve the problem.

ASP.NET 2.0 and "Validation of ViewState Mac failed" exception

If you get this Exception

[HttpException (0x80004005): 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.]

and

  • you know *for sure* that you aren't using a web farm
  • it seems that it appears when using built-in databound controls such as GridView, DetailsView or FormView which utilize DataKeyNames.
  • it appears if you have a large page which loads slowly for any reason

If following preconditions are true and you click a postbacking control/link while the Page hasn't loaded completely, you might get the "Validation of ViewState MAC failed"   exception. In this case be sure to check following post on ASP.NET Forums where this has been discussed quite thoroughly : http://forums.asp.net/1173230/ShowPost.aspx

It appears because GridView using DataKeyNames requires ViewState to be encrypted. And when ViewState is encrypted, Page adds   <input type="hidden" name="__VIEWSTATEENCRYPTED" id="__VIEWSTATEENCRYPTED" value="" /> field just before closing of the <form> tag. But this hidden field might not bet yet rendered to the browser with long-running pages, and if you make a postback before it "gets down", browser initiates postback without this field (in form post collection)

End result is that if this field is omitted on postback, Page doesn't "know" that viewstate is encrypted and causes the prementioned Exception. E.g Page expects to be fully-loaded before you can make a postback. And by the way similar problem is with event validation since __EVENTVALIDATION field is also rendered on the end of the form.

A way to overcome the problem is to set in web.config pages enableEventValidation = "false" viewStateEncryptionMode = "Never" /> Just note the security implications of these!
In the default condition will be randomly established manchineKey as ASP.NET code,
<the Configuration>
<system.web>
<machineKey validationKey = "AutoGenerate, IsolateApps"
the decryptionKey = "AutoGenerate, IsolateApps" Validation = "SHA1" />
</system.web>
</ the Configuration
If you have two Web Server, while another to verify when a ViewState,
validationKey decryptionKey or must be the same, so after validationKey must generate its own,
to the same codes to handle even ViewState cookie like.

The method of generating codes as follows:

string validationKey = GetKey(30); //20~64均可
string decryptionKey = GetKey(30); //20~64均可

protected string GetKey(int Keylen)
{
byte[] bytes = new byte[Keylen];
new RNGCryptoServiceProvider().GetBytes(bytes);
StringBuilder Builder = new StringBuilder();
for (int i = 0; i < bytes.Length; i++)
{
Builder.Append(string.Format("{0:X2}", bytes[i]));
}
return Builder.ToString();
}

After you can produce in Web.Config each Web Server website plus the <machineKey> to below
<the Configuration>
<system.web>
<machineKey validationKey = "3FF1E929BC0534950B0920A7B59FA698BD02DFE8"
the decryptionKey = "280450BB36319B474C996B506A95AEDF9B51211B1D2B7A77"
Decryption = "3DES" Validation = "SHAl" />
</system.web>
</ Configuration>

Reproduced in: https: //www.cnblogs.com/iksharp/archive/2009/04/27/1444742.html

Guess you like

Origin blog.csdn.net/weixin_33964094/article/details/93730365