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. AutoGenerate cannot be used in a cluster.
Is it possible that this error occures if the session expires ?
The MAC is validated on a per request basis unless you turn it off. I don't immediately see why a session ending could cause this error, but I'm not going to say it's absolutely impossible - you can check this for yourself by following the stack track and using Reflector.
This would be more likely to happen if multiple physical machines serve different requests in the same session, as opposed to a session expiring.
I got this error before and I was able to fix it by creating a static read only machine key. That way the key would never change after the first time it was set, so it would always validate. In my particular circumstance MAC validation was unimportant to me, but depending on your security concerns, you may want to further research the implications of this approach.
Related
I have 8 host behind LB and all of them are single process(not web garden). Despite setting all of them with the same machine key from iis as shown below, I'm still getting Invalid viewstate exception rarely.
There similar questions but none of them helped me(I've no server with pending updates or restart as in the other questions or i'm not using server.execute etc). So please don't flag as duplicate. Are there any alternative ways to prevent this exception?
Thx
Normally, This is because of the difference in Machine keys in different servers. We use Web Farm for High availability. In this case, if a Client sends a request then the Load balancer decides, which webserver to serve the request. It happens several times that another request might be served by another server. So here is the issue.
As we know, view stat is Client-side state management techniques and the data travels with the request and response. So if the view state is encrypted with some machine key and in other requests if handled by another server and that has different machine key, it would not be able to decrypt it and will through the error.
Every server generates a new key when it is set auto. and even sometimes any recycle of the app domain will generate a new key when it is set to auto. It means we cannot use the default auto-generated key. So here the solution is to use a specific key in the machine.config to prevent automatic key generation on each process start.
One another flexible approach, however, would be to add a MachineKey section to the web.config file of your web site. This would not require to make the changes on every web server.
another way is you could try to set below code in machine.config:
enableViewStateMac="false"
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. AutoGenerate cannot be used in a cluster.
I'm trying to find a way to prevent this error. It is occurring on my site when a user leaves the page open for 30+ minutes and fires an event that posts back. The way I understand this error and my issue is that the application pool has recycled and the viewstate is no longer valid. I'm not sure how to overcome this issue without keeping the session alive and wasting resources to do that... Any clever methods of completing this task?
According to this page there are 4 reasons why you might be getting this error:
application is running in a farm (multi-server environment)
worker process uses IIS 7.0* application pool identity
application pool configured by using LoadUserProfile = false
Page.ViewStateUserKey property has an incorrect value
* Note: this is no longer the issue starting with IIS 7.5 and up, according to article.
The big picture
The big picture of the problem is that a cryptographic key used to encrypt view state data is not being persisted (for one of those or combination of those reasons above), hence new cryptographic key is being generated which does not match original one. There are a few ways in which you can persist this key (or have your application use the correct key). See solutions below.
Solutions
Manually set MachineKey in web.config
Use aspnet_regiis utility to run managed application where machine keys will be persisted.
Run PowerShell script to persist machine key in HKLM registry rather than in HKCU registry.
Set LoadUserProfile = true to make HKCU registry hive be available to application.
Check for correctness of Page.ViewStateUserKey property to see if consumed value matches the value when key was generated (that is if you use this property).
This is a quick overview. For more details on any cause of the problem (as well as PowerShell script in #3) or solution of that problem please take a look at article to troubleshoot your particular case and to select most suitable for your purposes solution.
Before anyone says it, Yes we have validation & machine key explicitly specified in Web.config
Yet we are still getting this error from time to time. I've spent an awful long time trying to track down this problem and have come up completely empty.
We do have load balancing using TMG but we've reduced the farm down to 1 server for testing, and these errors still occur, so to my mind that rules out load balancing.
Because both ViewState integrity checks are occurring as well as Authentication ticket failures, this to me, points squarely at a situation where the Validation and Machine keys are being regenerated periodically, But how?! is the explicit key declaration in Web.config being ignored for some reason?
Once upon a time our setup worked perfectly, it was only when the servers were upgraded from Server 2008 to Server 2008R2 that this started happening, everything else in terms of the web apps is the same as the old setup.
What I'm thinking now is, if there's any way to get those keys at run-time, so we can see if they're changing somehow?!
Any other ideas welcome!
If you open a web page on one of the websites hosted on our server, leave it for 20 minutes and then submit a form, a Validation of viewstate MAC failed. error occurs.
What possible reasons could there be for this?
There's a few reasons this can happen:
Auto-Generated Machine Keys:
If your application pools have the default idle timeout of 20 minutes AND you're using auto-generated validation and decryption keys then each time the pool starts it will generate a new set of keys. This invalidates the browser's encrypted viewstate. You'll also find that forms authentication tickets for persistent tickets will also become invalid.
To overcome this set these keys to fixed values in:
`c:\%systemroot%\microsoft.net\framework\v2.0.50727\CONFIG\machine.config`
You need to add the <machineKey> configuration element to the <system.web> section. There's a pretty good article here that explains how to do this:
How To: Configure MachineKey in ASP.NET 2.0
Scroll down to the section on "Web Farm Deployment Considerations" and Generate Cryptographically Random Keys.
If you're running a load balanced web farm you also need to set each server's machine key to exactly the same value.
Incorrect form action value (3.5SP1):
There's also a case (post 3.5SP1) where if you set the action attribute of your ASP.NET form to something other than the page being posted back to and you're not using crosspage postbacks then you will get this error. But you'd see this right away:
Validation of viewstate MAC failed after installing .NET 3.5 SP1
Timing/Long Running Pages:
There's also an edge case for pages that take a long time to render where if the page is partially rendered and a postback occurs:
Validation of viewstate MAC failed error
Root Cause This exception appears because Controls using DataKeyNames
require Viewstate to be encrypted.
When Viewstate is encrypted (Default
mode, Auto, is to encrypt if controls
require that, otherwise not), Page
adds
field just before closing of the
tag. But this hidden field
might not have been rendered to the
browser with long-running pages, and
if you make a postback before it does,
the browser initiates postback without
this field (in form post collection).
End result is that if this field is
omitted on postback, the page doesn't
know that Viewstate is encrypted and
causes the aforementioned Exception.
I.E. page expects to be fully-loaded
before you make a postback.
It's taken us a while to find the answer to this as I had been informed that another IIS7 server I was comparing it to had been setup in the same way, by the same person.
It turns out the server with the websites which were receiving this error had been setup using Plesk, whereas the other server had not been.
It seems Plesk sets the Idle-Timeout to 5 minutes on the application pools, which is what was causing this error.
To change this do the following:
Open IIS
Click on application pools node
Locate your web application's application pool
Right-Click and select Advanace Settings
Set the Idle Time-out(minutes) property to 0 or increase it to 30+ minutes
For me, this solved the problem:
I've set LoadUserProfile = True in the application pool to make HKCU registry hive be available to the application.
Note: This is compatible with IIS 7.0+
I ran into this problem, and the scenario was a single web server hosting a very basic ASP.Net application. After struggling a lot I found this post, and that helped me to understand that the problem was the worker process getting recycled.
I find this quite harsh, as it's a scenario that an application might face and such a core error prevents you to handle it properly. As far I could see, this is originated because the default configuration for handling this keys will use the machine.config that states that keys are automatically generated and isolated per application. I think in this cases ASP.Net a temporary key and store it at the worker process level, and when that worker process is gone the issue arises and can't be handled.
The alternative of configuring the machine key solves the problem, clearly is better to set it on the web.config file rather the whole machine.config to keep it at the lowest granularity level.
Another option is to disable the view state MAC check, also through web.config. It will depend on the security level of your application and the risk of having the view state tampered with.
And the best option is to avoid using view state with a MVC application.
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. AutoGenerate cannot be used in a cluster
As I found out, there was a <base ....
tag in header part of my master page, that I added in last tie and before publishing. This tag specify a default URL and a default target for all links on a page. This was the main cause of the fault, this time.
I'm having a problem with a web app I'm managing. Users starting receiving the following error occasionally:
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. AutoGenerate cannot be used
in a cluster.
The problem is that it's not a cluster - it's a single Windows 2003 server. After digging around, it appears that adding a machineKey section and some extra attributes to the Pages directive in my web.config resolves this error:
<machineKey validationKey='MACHINE KEY SNIPPED'
decryptionKey='DECRYPTION KEY SNIPPED'
validation='SHA1'/>
<pages validateRequest="true" enableEventValidation="false">
After changing these two things in my web.config, the error goes away, but now I have a new problem - Instead of an error that my viewstate is invalid, the app just "Forgets" who my user is, and sends them back to the login page. Now, the users are browsing through the application, and then they're unexpectedly sent to the login page, even after they've already been logged in for a few minutes. While I can't force this to happen, it usually happens within visiting 10-12 different pages, so pretty frequently.
I'd love a resolution to this - does anybody know what else might be causing the viewstate error on a single server, or what I can do to ensure that it's validated properly?
It sounds as though the worker process is recycling itself (assuming you're storing session state in-process). Picking a fixed key means that the viewstate is still valid when the process comes back up, but you've lost the session state. You could try storing the session state in a database, but I'd be more concerned to fix the underlying problem. Does your application suddenly allocate vast amounts of memory, or anything like that? Is there anything suspicious in the event log?
It turned out that this began happening when I added additional worked processes to the app pool that was running our application. Because the session state was being stored InProc (and not in a state service or a SQL Server), it was losing track of who the user was when it switched them between working processes. For now, dropping the number of processes on our server back to one corrected the problem, since raising it didn't seem to have any improvement in the first place.