If you deploy ASP.NET websites to a web farm, you may run into this perplexing System.Web.HttpException:
A lot of people need security. The reason this is hidden is so someone can’t copy the URL with the viewstate and post it somewhere else. I could capture the URL and utilize it to gain access to things I should not have access to. Setting the passwords the same is the BEST option.
Well, I was kidding. This is an intranet, so it really doesn’t matter if a request meant for server 1 of 5 goes to server 3 of 5 instead.
Thank you very much.I
Thank you very much for the information! I am running a single server with two processors (web garden), and received this error.
Could this page element be added to the machine.config? I am working on an Intranet site with 10 Virtual web-sites (inherited this problem … 
).
If you use a validationKey (We do in server farms), you will still need to specify the decryptionKey=“AutoGenerate,IsolateApps” in the machineKey tag. Or specify a key here to decrypt with.
Helped me resolve View State error. Great site.
I get an error when I add a decryption key
While navigating between pages of my application from a remote computer, I have received the “Authentication of viewstate failed” error. After modifying the “pages” element in Web.config, as per Jeff’s suggestion, there is no error message, but any attempt at loading anothe page (via the Server.Transfer(“page_name.aspx”) command fails and the first page is displayed agaim. Any suggestions ?
The enableViewStateMac=“false” worked for me in the web.config file. We also had the encryption “bad data” error and that was solved by setting the Web Garden to 1.
Heads up all who use this method. If you use the enableViewStateMac=“false” method, the end user can muck around with your internal variables. Picture people being able to change the prices of things in their shopping cart right before they checkout and you’ll get an idea of why this is dangerous to say the least. Just set the password the same if you’re using multiple servers… MUCH safer, although the kiddies will probably start trying to guess at easy strings soon 
badguy: you’ve been watching too much TV lately. If you let the prices being changed on the client side, well, I don’t think you are developing robust applications. You show qty, prices, total to your client browser because the client has to know how much is his/her order going to cost. But once the order is submitted, you only need the part# and qty requested; the total is calculated in the backend the same way it was shown to the client. You DO NOT get pricing from your client.
This comment is not related to web farming, but I was getting the same error. It was happening on my machine only and none of my colleagues were getting it. I dug a little deeper and found that there is a browser helper object named ‘qlink32.dll’ that was putting additional script on the page. I used HijackThis.exe to locate and kill the BHO and now the error is gone. Hope this might help save someone sometime.
Pablo makes a good point. Security is the responsiblity of all developers and the enableViewStateMac is a safe-all.
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 and get toyed around.
Turning it off worked well for us but if you’re doing ebusiness or have security concerns you should use the same passwords.
Can someone explain the option of setting the password the same as suggested by some users. Tks
How and if you encrypt ViewState depends entirely on how your app is built. If you’re like me and you try to stay away from ViewState at all costs and only store bare essentials there to get the page back into its core state, then you don’t have to worry about somebody mucking with ViewState. However if you’re one of those folks that uses ASP.NET’s default for ViewStating everything then you better encrypt things. It’s only common sense.
It’s better safe than sorry so if you’re not sure what’s in your ViewState encrypt it and use common keys across applications…
Really useful tip of setting enableviewstatemac=false
, thanks
To pablo, posted at 8 October 2005:
ViewState is a dangerous thing. Imagine your SQL Data Queries which is written in your viewstate been able to change by your clients to UPDATE or INSERT methods. Even if you use a secured viewstate, talented hackers can work around this and hack your server key and produce their own viewstate values.
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.