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.

I encountered this problem when upgrading a production server from 2.0 beta to 2.0 full. Firstly, I saw the "Validation of viewstate MAC" problem which I tried to solve with the pages enableViewStateMac="False" fix, but this caused an invalid http operation exception saying that the event validation tags in the pages were incompatible with the viewstate validation. So.. switched that off with the other two flags to the pages tag.
Since that now rendered the viewstate open to tampering, I decided to look deeper into it, adding the machineKey tag as specified in this article (in machine.config.comments rather than web.config.comments), but still saw decryption exceptions being caused.

In the end, it turns out that IE was caching the initial page's viewstate field even between browser exits. The solution was to clear IE's cache and reload the page!

I /hate/ IE.

But thank you very much for the information! All of you :)

~aFx

So will this setting in the webconfig take care of view state persistance across servers in a web farm?

<system.web>
<pages enableViewStateMac="false" />
</system.web>

thanks,
anabhra

Thanks for ur help.
My problem is now solved.

Thank you, thank you, Jeff! Good information -- describes exactly what I'm seeing on our web farm.

I owe you a cold drink, or a hot coffee. Your choice.

It seems however that the autogenerated one can also affect clients on load balanced connections even if you dont have a farm.

Getting this error in a web garden scenario. Any definite feedback on what needs to be done here? (Assume viewstate cannot be turned off and must be encrypted).

i tried setting enableviewstatemac=false but it resulted in expiring of sessions.

I am also looking for an answer on what Sanin Saracevic has posted, the issue is with a web garden but not consistent.

I have been reviewing all the tips and there are some good ideas there and lot of feedback that is helpful.

To balance in a farm across servers could you override the machine key setting in the web.config instead of modifying the machine.config with the generated validation Key and decryptionkey:

"
decryptionKey="" validation="SHA1"/>

I look forward to getting a response on the web garden issue.

I have it in web.config file the validationKey with 3DES encryption. But, still I am getting inconsistent exception. It only breaks on certain pages.
<pages buffer="true"
enableSessionState="true"
enableViewState="true"
enableViewStateMac="true"
autoEventWireup="false"
smartNavigation="true"
validateRequest="true" />
<machineKey
validationKey="9BD0DB6D8DD5A49458602F4973451D1DD02BAB6D33DB587460407A39D6" decryptionKey="05EA41989E75E5EF942DA4A69C5" validation="3DES" />

Copy the same machineKey on each server. It seems like the __EventTarget value is get stuck in the __ViewState and I have no idea why?

Thanks very much.

Thanks very much.

Its really helpfull, My problem is now solved,

Thank you a lot, I was searching for this exact code.

Great hints
Thanks man!

Very informative. Thank you. Was unaware of the enableViewStateMac attribute. The machineKey/validationKey error might also be fixed by using sessionState mode of StateServer or SQLServer? Or would enableViewStateMac="false" still be required? Hrmm.

Some additional suggestions for web.config settings here:
http://www.thescripts.com/forum/thread660517.html

If you are running identical multiple server, I've found the best thing to do is optimize one machine.config on one server then copy it to all others. This way they are all running the same validation key. That way you can enable enableviewstatemac and it won't matter which one gets hit. Not AS secure but works well with load balancing.

A note of caution for those running SharePoint 2003 server farms. We threw the switch to enable Fips 140-2 for .gov and the farm blew up. We've customized code including web parts, web services and now need to back it all out till we find the culprits. Not even certain if a fresh OOB SPS 2003 can manage the settings. Does anyone know?

tx

dave

To prevent error messages I have used enableViewStateMac="false" and I use the StateServer.

I do not have error messages, but when multiple users try to do the same thing in my webapplication, it is possible that sessions get mixed up: complete horror scene!

This often happens a few seconds before a session is lost because of the time out. I am not sure what to do.

Can anyone help?

Peter

putting enableviewstatemac="False" in page directive solved my 10 days old problem thanx a lot..

Great Posts.
For those that need to have viewstate enabled across a webfarm, there is a great article that shows you how to add the keys to the web.config file that will let you encrypt and decrypt the viewstate with the same keys. The link is http://www.devwebpro.com/devwebpro-39-20061228ASPNETmachineKeyGenerator.html Adding these keys to the web.config and distributing solved all the problems.
Additionally, you'll need to make sure that you're using either sqlserver or a sessionserver to maintain session on a farm, but that's another discussion.

sdfgfg

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. http://www.butalbitaldrug.com

From an ealier post:

"Imagine your SQL Data Queries which is written in your viewstate been able to change by your clients to UPDATE or INSERT methods."

Why would anyone place sensitive information in the ViewState-- or anywhere on the client for that matter? Anyone with a curiosity about what a form tag is doing would be able to break a site. It seems like any developer worth his/her curly brackets would know this.