Elusive View State Errors - Part II

We've done some more troubleshooting of the elusive The viewstate is invalid for this page and might be corrupted error (see part I). Browser cache didn't seem to be the primary source of trouble even though its caching level did make a difference.

This error occurs pretty consistently when a user clicks a link in an email which takes him/her to our product. Or if you click the same link from a Word document, right off the bat a page would fail with the said error message. I decided to set IE's caching option to Every visit to the page. With this setting a page would fail consistently. With other caching options it was hit-or-miss. Weird.

I decided to look into our view state validation and encryption settings in web.config. To enforce maximum security of the view state we set a long validationKey and a long decryptionKey and have it 3DES encrypted. If you're new to this, see my article ASP.NET State Management: View State.

It is always encouraged to enable Message Authentication Code (MAC) validation by setting enableViewStateMac="true". It's a good idea to have it enabled to prevent spoofing attacks, but once I turned it off the error rate went down.

Here's what's bothering me: I have a gut feeling that the algorithm for calculating MAC is flaky when you hit a page from an email, or MS Word or some other external source. I don't know why changing enableViewStateMac makes a difference but it does. I don't know what ingredients go into the MAC sauce, or maybe a session is established differently, or the Referer header is taken into account or what. More digging is on the way.

Keep up the fight! When I first came across this problem I immediately suspected caching as the culprit as well. I'm testing a web app with various devices and browsers (desktops, laptops, PDAs, etc) and in particular I've noticed that certain PDAs are much more prone to encountering this error. They are usually the ones with older and "dumber" browsers than stubbornly insist on caching pages even when I include every anti-caching header under the sun. I suspected it was a matter of the PDA displaying a cached version of the page to the user with an old VIEWSTATE value, instead of the one returned by the web server. Then of course when the postback occurs the VIEWSTATE received by the server is not what it's expecting. But really my limited knowledge ends there. Good luck!