I need some explanation to this.
I've added a routing functionality to my website using the System.Web.Routing library. This has added some unexpected behaviors while trying to submit forms where an viewstateMAC error continuously is thrown. I've used the method in Appendix A to generate a clean machineKey and then located some of the problem to the use of view state encryption.
I'm now trying to set the view state encryption in my configuration file in order to pass the viewstateMAC correctly but I keep running into errors. If I set the parameter to 'Auto' or 'Never', the page simply reloads but never actually trigger any submit. On the other hand it seems as If the page is locked in PostBack as if I try to reload the page I get a confirmation box asking me if I want to post the form once again. If I set it to 'Always' I get a failed viewstatMAC in return. Either way nothing posts.
<pages controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID" validateRequest="true" enableEventValidation="true" enableViewStateMac="false" enableViewState="true" viewStateEncryptionMode="Auto" maxPageStateFieldLength="400"/>
I guess the encryption is just a part of the problem. Either way I'd appreciate some explanations to why this error occurs while encrypting the viewstateMAC and what I should do to fix it.
I don't know if any code examples are required but please let me know if you want any.
Related
i am facing the dreaded:
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.
Error.
Ok so i looking it up and found that it can be caused by two things, viewState which can not be verified by the page, and/or events that can not be validated.
I put
<pages enableEventValidation="false" enableViewStateMac="false" viewStateEncryptionMode="Never">
In my web.config to stop the problem, but that hardly seems like a fix to me.
The thing is, i never even used viewState in my application. I know that asp.net uses viewstate by default to store some things, but i doubt the default values stored here will cause any errors.
I noticed that the problem seems to happen when i postBack and the page has not finished loading yet.
Thanks
Edit: Please, can someone test my website www.vittoriosaStarsNursery.com and see if you get the error i got above? I dont get it locally but people keep telling me they are getting it.
Isnt this just a case of putting a one liner in your web.config
<machineKey decryptionKey="A4B12CCDD50E95F8GB9GFH6JKAT4Y0U0I2OF2DF2AAFE5AB46189C,IsolateApps" validation="AES" validationKey="480CDF2AS9S9AS5CFDGF0GHFH9JJH4KHKAKLJ2L9F3SAS82A6C16911A29EF48903783F94529C21570AACB72766FB38CD4CE7B85B0ACE3149DC5FC1CCF1AA1CECE3579659996593B06,IsolateApps"/>
One thing I have come across that causes this issue has to do with the recycling intervals of the app-pools on the webserver.
I found this by looking at the event information in Eventviewer/Application logs and the "Task Category" called "Web Event". Then for the time period that this event took place I looked to see if there were any recycled events that took place just before that (Eventviewer/System logs and the "Source" called "WAS".
By default an app-pool will recycle every 1740 minutes (29 hours). If this recycle happened while a user is busy on the site and send post back to the server, the server no longer recognizes the session/viewstate and rejects what is being posted back.
To overcome this from our perspective is to set the recycle event to happen at a specific time of the day when we don't expect activity on the site. In our case 3am in the morning.
Hope that helps someone out there.
You're not going to like my answer. This error is basically unavoidable in webforms. My solution was to leave webforms for MVC3 and razor.
I noticed that the problem seems to happen when i postBack and the
page has not finished loading yet.
this is one of the easiest ways to cause this error. In ASP.NET 3.5 (or 4.0) there's a setting that you can make sure viewstate gets loaded very early in the page to try to help diminish it. It still doesn't solve it.
Chunking the viewstate doesn't solve it.
There is just something inherently wrong to the way webforms works that this error will plague your application at random times forever.
At my site, this meta tag were causing the error:
<base href="http://www.SITEURL.COM" />
I have a dropdown, I update on another dropdowns changed selection. So when the postback happened (dropdown #2 changed index), I got the exception.
I've tried everything else from applying machinekey to web.config and setting theese attributes at the page
EnableViewState="false" EnableViewStateMac="false"
I am using VS 2010 against a Windows Web Server 2008 and what I eventually found was that I had two keys set for the same service in the appSettings section of webconfig. I went to IIS and checked the Application Settings on the virtual directory and got an error, fixed it in the WebConfig and the problem resolved. I did create a machine key but that did not fix the problem. Nor did the
pages (...) validateRequest="false" enableEventValidation="false"
enableViewStateMac="false" viewStateEncryptionMode ="Never"/
Settings. FWIW ...
I used this Microsoft article to create my own machineKey validationkey and decryptionKey. As others have stated, this can be placed within the system.web section of web.config, though there are security concerns if other people get hold of the key.
Well, yes i suppose disabling encrypted viewstate solves the problem but i have never tested it nor do I advise it. Viewstate stores the state of controls and is also very convenient for storing persistent variables.
Take for example you work for a garage and have a list of jobs. You go to a page that lists the jobs. Now you click a job which goes to another page appending the jobid (eg. job.aspx?id=1). On that page, there is a checkbox which marks the job as complete. Once you tick that checkbox, it posts data back to same page and writes to the database that the job is complete. But how does the server know which job to mark as complete because you have only posted back true or false from the checkbox. However, if the first time you load the job details page you record the job id in Viewstate, then when you post pack the checkbox, you can read in the jobid from the viewstate.
Why is it not good to use unencrypted viewstate?
Imagine what the server has to do to mark the job as complete. It probably has to run an sql command to update the database. Something like UPDATE jobs SET completed=GETDATE() WHERE id=1.
If your viewstate wasnt encrypted and i could add my own job id, I would put something like '; DELETE FROM jobs;' which would then cancel out the initial UPDATE command and delete ALL your jobs... not very good for the garage :)
I have an ASP.NET website that has been deployed since 2008 with plenty of users. From time to time, I've made updates to the site and uploaded those changes to the server without problems.
However, today, I'm trying to run the site on my development environment and I keep getting errors any time the code tries to access session state. It appears System.Web.HttpContext.Current.Session is always null!
Any suggestions on where to look? It's been a while since I worked on it and am not 100% sure if I've worked on it with the current version of ASP.NET (4.0).
Other than that, the code's been working fine and I haven't made any changes since it was last working.
More Information
I've spent all morning on this but I apparently have a larger issue.
If I step through the code, I see that my page Load handler executes. At this point, Session is not null. After that, my specialized master page executes. After that, my general master page executes. I then step through load events for a couple of controls. This all seems very normal.
Then, if I keep executing, suddenly I'm loading a specialized master page for another page and Session is now null!
If I hit F5, it the original page shows. But somehow it is causing the other page to load and without session state. If I turn off debug mode, it appears to run normally.
Obviously, I have something strange happening. I need to determine why the other page is being loaded.
Try to put a static page, something like Test.aspx and browse to that page. If it gets loaded, try to use Session property of the page in code behind. Do you still get the error? In that case, Session doesn't load. I suggest creating an HTTP Module and hooking into a method which is responsible for loading Session info. See what's wrong.
Just a guess - did you deactivate sessionState for any reason? Anything like this:
<sessionState mode="Off"/>
My apologies. The information I provided was completely misguided and was not sufficient to resolve the issue.
The problem was actually due to some custom error handling that redirected to an error page. This was configured in web.config. This error page was using the master page that my code was mysteriously executing.
Apparently, an error was occurring within the GridView control. This is ASP.NET code and not my own, so I was unable to step through it or catch it with a regular handler.
This was hard to understand. If I was executing the Load event handler of my error page, then it would've been obvious. But it appears to have skipped over that. Thus, my confusion.
Try checking the global.asax file or any other pre-load events and make sure the Session is not set to NULL explicitly.
Maybe your erring master page is calling code from some external class where the session object is not available?
We have a site were trusted users can add some Javascript tracking code into a text box for submitting, so naturally we have turned off Validation by adding the ValidateRequest="false" into the Page Directive.
However it we seem to be getting the error again all of a sudden : A potentially dangerous Request.Form value was detected from the client , Now we cant add ValidateRequest="false" into the Config or the Master page this page inherits from. So how do I allow Javascript to be posted, what is overridding the ValidateRequest?
We are using .Net 3.5
Probably something else, not the Page, is triggering the error due to the breaking changes made in the framework.. if you can't edit the web.config I fear you're pretty much stuck.
The following error occurs when my webpage is idle for more than 5 min.
Error: Sys.WebForms.PageRequestManagerServerErrorException: 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.
Source File: http://www.dial4jobz.com/ScriptResource.axd?d=Xl5p0QQ_qaR3K9bIVhwC3LyqjOX_oAKyeLj_-uS5j1VoFExVtm3XAHiq64EGJt04xntLJvh-9y3pvN3dvKgg5b6sQwkFvX7GT4f0aKn7iyc1&t=73e6f815
Dono, wat is the cause of this error.. I'll open a web page and after 5 min when I'm accessing it, it is showing this sort of error.. I don't hav any clue that why this error occurs.. Plz, give me any idea???
use the below code and try
<pages validateRequest="false" enableEventValidation="false" viewStateEncryptionMode ="Never" />
if u need more info kindly refer the link below,
http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx
http://forums.asp.net/p/955145/1173230.aspx
I had the same issue, this is the two solutions I found and that might help if you are not using a WebFarm:
1. Disable ViewState MAC
On your page (.aspx) #Page directive you can add the attribute EnableViewStateMac="false". By doing this that will disable the check and then the issue will goes away.
Unfortunately Microsoft doesn't recommend to do this for security reasons:
This attribute should never be set to false in a production Web site,
even if the application or page does not use view state. The view
state MAC helps ensure the security of other ASP.NET functions in
addition to view state.
Source: Microsoft
2. Check HTML
There is a bug in ASP.Net causing this issue when the "action" attribute is set in your <form> tag. For example:
<form runat="server" action="page.aspx">
By removing this attribute that will remove the issue, so you should now have something like:
<form runat="server">
Obviously this solution may raise other issues, it depends on your application. One big problem is when using Ajax to load pages.
3. Avoid ViewStates
In some cases when using Ajax it could be very easy to get rid of ViewStates. You can send Ajax requests to your server for performing operations and then display the result, no need to use a ViewState. By doing this you won't have an issue about the ViewState validation.
I also found other suggestions on those pages that might help you if what said above doesn't fix your problem.
Hai vaishu,
Have a look at this validation-of-viewstate-mac-failed-error
I've inherited an ASP.NET application that contains a login screen. When you first start up, or you haven't done anything for a while, it comes up. It turns out we don't need this extra layer of security, and I'm trying to remove it. I thought I removed the code that was doing the redirecting, but it's still going to the login page, even though I've told the app to use default.aspx as the start page, and ensured that default.aspx contains no code that should trigger the redirect (it's using a master page, but the master page also contains nothing that should be redirecting). Where else might it be redirecting to the login page?
Look for <authentication> sections (should be under <location> sections) in your web config and delete them
Sounds like it could be forms authentication in effect.
In the web.config file change the authentication mode value to none and see if that makes a difference.
<authentication mode="none" />
Found the problem. Even though I thought I had all the redirect code removed, there was still some buried in a user control on the default page. Removing that allowed me to bypass the login screen. So, I can't mark any of the responses as the answer, but I gave them all up votes as they were all good answers.