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
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 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?
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.
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?
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.
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.
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.
