An interesting "Validation of viewstate MAC failed" error is found and solved. viewstatemac

An interesting "Validation of viewstate MAC failed" error is found and solved. viewstatemac

 

In ASP. NET, View State is widely used. As a hidden field, it can help the server "remember" The changes of the client, so that after the client receives the server's response to PostBack, the values set before PostBack can still be displayed (see http://msdn.microsoft.com/en-us/library/bb386448 (v = vs.100 ). aspx)

<Input type = "hidden" name = "_ VIEWSTATE" id = "_ VIEWSTATE" value = "..."/>

To prevent the ViewState in the PostBack of a malicious client from being interpreted, ASP. NET checks Each ViewState using the message Verification Code (MAC. However, once the server cannot correctly interpret the ViewState returned by the normal client PostBack, the entire application will stop working. For example, the error "Validation of viewstate MAC failed" appears.

In general, once such an error occurs, the following situations will be taken into account:

1. Is there multiple Web servers running under Server Load balancer. If yes, each server needs to use the same MAC to encrypt and decrypt ViewState. Otherwise, if the server Load balancer environment does not fully implement Session Affinity, this error will occur.

2. Test whether this error occurs during local access. If yes, in addition to attempting to regenerate a new MachineKey (see the http://blogs.msdn.com/ B /amb/archive/2012/07/31/easiest-way-to-generate-machinekey.aspx), you can also use Process monitorto trace the file and the name of the registration table at the time of the problem, it is not because w3wp.exe lacks permissions and cannot obtain information related to the MachineKey.

3. Capture the network package on the client and server, and compare whether the ViewState is changed by the Intermediate device. This situation is rare, but we have also encountered it. This is a complicated situation. If the connection is SSL and packet capture is not available, the client must use Fiddler, and the server must use additional diagnostic logs or Debug methods.

4. related to specific code, especially special settings for ViewStateUserKey.

Here we talk about a practical problem encountered in a large production and application environment. It is related to the above situation, but there are some interesting changes.

There are multiple Web servers in this environment, and load balancing is adopted. When a customer attempts to log on (login. aspx), the customer will always encounter the "Validation of viewstate MAC failed" error.

At first, it was suspected that the MachineKey of WebAppication on different machines was different. Check the configuration in Web. Config. Each machine is the same:

<system.web><machineKey decryptionKey="6284D74F8D9745C38712047622FFA047B02CA5C4049FB74E,IsolateApps" validationKey="137B974DC38A910D946AAF3ADF1D0386072170236F39C8165098035126FE7DFDF68C7BD3646052CE1769A47A45F098A65CEC3089523543370DD37830A5B2D13,IsolateApps" /></system.web>

In addition, Session Affinity of Class C is also set for Server Load balancer.

Later, we found that this problem occurs even when accessing the local machine. After the application pool identity is changed to Admin, the problem is the same. The table is independent of the permission. The MachineKey is re-created and remains unchanged.

Pay attention to the code. The page code is obtained for Review. In the Page_Init of the Login page, the ViewStateUserKey is displayed.

protected void Page_Init(object sender, EventArgs e){        this.ViewStateUserKey = this.Session.SessionID; }

On the surface, there is no problem with this writing method.

After Fiddler is enabled on IE (the connection is SSL), no Cookie information is found in the client's PostBack. This is the direct cause of the problem:

A. when accessing the Login page for the first time, A random SessionID a is embedded in ViewState.

B. in PostBack, because no Cookie is returned (ASP. NET SessionID is stored in the Cookie by default), the server determines that the client does not have a SessionID, and then uses a new SessionID B as the ViewStateUserKey. in this way, the last SessionID A is obtained from ViewState, which does not match the new one. The error occurs.

But why does the client not send cookies?

When the server first replied, there was no Set-Cookie field in the HTTP Header of the client.

This is ASP when no Session variable is assigned. NET default behavior (SessionID is formed every time a request is sent, but it may not send a Set-Cookie to allow the client to retain this SessioID, unless there is an action to assign the Session variable)

The direct solution to this problem is to add a statement in this Page_Init as soon as possible:

protected void Page_Init(object sender, EventArgs e){    this.ViewStateUserKey = this.Session.SessionID;    session("forViewSate")="value"  }

In this way, the server sends the SessionID back in "Set-Cookie", and the client can also use the Cookie to keep the SessionID. The problem is solved immediately.

For more information, see:

Microsoft technical articles discuss how to deal with "Validation of viewstate MAC failed ":

Http://support.microsoft.com/kb/2915218