1

Running the ASP.NET webforms run the application works fine. When the application is idle for 4 to 5 minutes, it is giving this error:

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.

How can this be solved?

p.campbell
  • 98,673
  • 67
  • 256
  • 322
Surya sasidhar
  • 29,607
  • 57
  • 139
  • 219
  • Vote to close, exact duplicate of [CryptographicException: Padding is invalid and cannot be removed and Validation of viewstate MAC failed](http://stackoverflow.com/questions/1821243/cryptographicexception-padding-is-invalid-and-cannot-be-removed-and-validation-o) – Chris Marisic Sep 20 '10 at 18:03
  • Sadly this is both a bug and a feature of ASP.NET. – Chris Marisic Sep 20 '10 at 18:04
  • i have added both page settings as false and machine key. same machine key in both application. still it shows same error – Razack Nov 14 '15 at 08:41

4 Answers4

2

This free online tool: http://aspnetresources.com/tools/machineKey generates a machineKey element under the system.web element in the web.config file. Here is an example of what it generates:

<machineKey validationKey="1619AB2FDEE6B943AD5D31DD68B7EBDAB32682A5891481D9403A6A55C4F91A340131CB4F4AD26A686DF5911A6C05CAC89307663656B62BE304EA66605156E9B5" decryptionKey="C9D165260E6A697B2993D45E05BD64386445DE01031B790A60F229F6A2656ECF" validation="SHA1" decryption="AES" />

Once you see this in your web.config, the error itself suddenly makes sense. The error you are getting says

"ensure that configuration specifies the same validationKey and validation algorithm".

When you look at this machineKey element, suddenly you can see what it is talking about.

Modifying the pages element under the system.web element may not be necessary with this in place. This avoids the security problems associated with those attributes.


By "hard coding" this value in your web.config, the key that asp.net uses to serialize and deserialize your viewstate stays the same, no matter which server in a server farm picks it up. Your encryption becomes "portable", thus your viewstate becomes "portable".

I'm just guessing also that maybe the very same server (not in a farm) has this problem if for any reason it "forgets" the key it had, due to a reset on any level that wipes it out. That is perhaps why you see this error after an idle period and you try to use a "stale" page.

Todd
  • 439
  • 5
  • 5
0

This isn't your problem but it might help someone else. Make sure you are posting back to the same page. Check the action on your form tag and look at the URL your browser is requesting using Firefox Live HTTP Headers.

I ran into this because I was posting back to a page with the same name but a different path.

mhenry1384
  • 7,538
  • 5
  • 55
  • 74
-1

Modify your web.config with this element:

<pages validateRequest="false" 
       enableEventValidation="false" 
       viewStateEncryptionMode ="Never" />

Any more info required, refer to the ASP.NET Forums topic

p.campbell
  • 98,673
  • 67
  • 256
  • 322
solairaja
  • 966
  • 7
  • 17
  • check properly because the same issue i too faced and used this code change it worked for me. – solairaja Dec 10 '09 at 11:30
  • Mr. Solairaja the code which u gave is it related to web.config am i right? so i have to paste in web.config file – Surya sasidhar Dec 11 '09 at 04:28
  • Thank u Mr. Solairaj it is working fine i implemented. Thank u for response. R u Indian give response? ok – Surya sasidhar Dec 11 '09 at 09:23
  • Sorry !! i missed your few questions. Actually these code should come on the aspx page where ur working not in web.config file. Any how it worked for you. congrats. Yes i am indian, working in Dubai. – solairaja Dec 13 '09 at 05:17
  • 12
    Using this code will massively decrease the security of your ASP.NET application. You should never use this code in production unless you're inside a corporate firewall. – Chris Marisic Sep 20 '10 at 18:00
  • @Chris If you aren't using the ViewState to hold anything important, there's no reason to validate it. – mhenry1384 May 18 '12 at 16:05
  • @mhenry1384 that's not entirely true. ViewState is also responsible for control state. By not validating viewstate hackers could maliciously change your data depending how you do things. – Chris Marisic May 18 '12 at 16:22
  • @Chris Right, but look at your average corporate website. You might use postbacks for a search textbox, submitting a contact form, and that's about it. It's hard to see what damage a hacker could cause on a site that's basically read-only, which I would argue is the vast majority of sites. – mhenry1384 May 19 '12 at 17:38
  • @mhenry1384 how about altering pricing information of your shopping cart object that's sitting inside of a gridview on a checkout page? – Chris Marisic May 21 '12 at 20:43
  • @Chris I would consider pricing information "important" and my original comment started with "if you aren't using the ViewState to hold anything important..." – mhenry1384 May 22 '12 at 15:40
  • @mhenry1384, Ironically, search boxes are the ideal attack target, if you disable validation, that's the _first_ place you'd want to implement thorough validation to prevent XSS et al. There are however a lot of areas where it is _really_ hard to notice what damage a hacker could do and that's why this security feature was implemented in the first place. – Saeb Amini Nov 09 '12 at 09:15
  • This answer does not highlight the risks of using this solution – Corey Aug 10 '22 at 14:23