I am getting the following error whenever I click on a postbacking control
HttpException (0x80004005): 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.
I am not using a Web Farm or cluster server. I have even tried setting the page property EnableViewStateMac to false but it changes the error message stating
The state information is invalid for
this page and might be corrupted.
What could possibly be wrong?
There is an article about this here: http://blogs.msdn.com/tom/archive/2008/03/14/validation-of-viewstate-mac-failed-error.aspx .
The basic problem is that Your page hasn't completed loading before You perform the postback.
A few different solutions are in the article listed above:
1. Set enableEventValidation to false and viewStateEncryptionMode to Never
2. Mark the form as disabled and then enable it in script once the load is complete.
3. override the Render Event of the page to place the hidden fields for Encrypted Viewstate and Event validation on the top of the form.
But the main problem is that the page load slow, which should be fixed (if possible ASAP). It can also be good to apply solution 2 above as well as there will always be trigger happy users that will click faster that the page loads no matter how fast it loads :-).
/Andreas
I have encountered the same problem with a custom build ASP.NET control which was dynamically reloaded and rebuild on every POST / GET request. Thus the page sending the POST request was not the same as the one recieving the response.
If you use any custom or databound controls look closly how they behave on a POST back.
Related
I am new to asp .net web forms and I am having trouble in efficiently handling the broswer refersh. I have used the below link to do the same.
http://geekswithblogs.net/Vipin/archive/2011/06/08/detecting-browser-refresh-from-code-behind-in-.net.aspx
However , the problem with the above approach is that the button click is throwing the below error:
Invalid postback or callback argument. Event validation is enabled using in configuration or <%# Page EnableEventValidation="true" %> in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.
Any help would be appreciated.
I suggest you to use Post/Redirect/Get pattern
If a web user attempts to refresh the page this pattern avoid the HTTP POST request to be resubmitted.
Just force a redirect at the end of the page that receive the posted data.
Moreover rely on session like example does is never a good practice
I have my web application where I have set the enableViewStateMac="true" under attribute in web.config. I was trying to validate different security aspects of view state.
However, there is one scenario, where enableViewStateMac="true" fails to validate the _ViewState has been changed. I am using the "TamperData" plugin of Firfox browser. Using Tamperdata, I completely remove the value of _VIEWSTATE and then POST the web request. The POST request gets posted successfully and page redirects to the next page successfully without any error.
Though, as per my knowledge and security testing so far for enableViewStateMac="true", It seems to me the EnableViewStateMac only works/validate weather _VIEWSTATE is being tampered or not. But it doesn't validate if _VIEWSTATE Value is being deleted/removed completely.
Is there is a way I can validate this also (that is if someone has completely removed the value of _VIEWSTATE)?
Thanks in advance,
Happy coding :)
When the page is generated, store a value in ViewState. Then, on post back, read that value back out. If __VIEWSTATE isn't present you'll receive a null value back at read time.
Page Load, as a sentence of 2 words, means when the page is loaded, means, when all elements are loaded.
Let's say I have a page called Ask.aspx, and this page is only allowed to users who have signed in, so technically I would write something like this :
if(Session["id"]==null)
Response.Redirect("Login.aspx");
This mean, that I'm testing the Session AFTER the page loads, theoretically, I think it sounds wrong, now of course I won't notice it, it will be fast, I will try to access the page, then I'm redirected to Login.aspx, but... is it correct to test the Session on Page Load method?
The Page_Load is part of the page lifecycle. It is called when the Server loads the page, not when the Client loads the page...
So this is the correct place to check the Session Variable...
You're actually saying: Before I post the page back to the client, check if I have the ID property set for this session... If I don't - tell the client to redirect to the Login.aspx page...
This is the correct way of doing this...
I recommened you also read about Server.Transfer. The difference between it and Response.Redirect is that in Server.Transfer the server itself "redirects" to another page and outputs the result of the new page back to the client (without the client knowing about it).
If you are trying to limit access to specific pages, you would be better off using forms authentication.
http://support.microsoft.com/kb/301240
It is fairly easy to setup and it allows checking of credentials before the request is passed to the asp.net pipeline. In what you are doing, your page goes through the entire lifecycle (controls are rendred and bound to data, access to database, calls to web services etc.) before the request is rejected. Depending on your situation, this might be costly and will not scale well.
Edit: You can also hook in to the AcquireRequestState event in the global.asax. This will also spare the entire page life cycle.
Here's an interesting one for you.
I've got my custom 500.aspx setup which is called when a 500 error occurs in my application. The 500.aspx also sends me an email with the error details.
I've noticed one small problem.
If you attempt an xss attack on the 500.aspx itself, the 500 page is not called.
This is obviously some sort of logic issue.
In fact, microsoft themselves suffer from the same issue.
See it in action here
http://www.microsoft.com/500.aspx?aspxerrorpath=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
How can I prevent this?
Ed
If you attempt an xss attack on any page, the custom error page will not be called (here's another random page on Microsoft.com with xss in the querystring).
The behavior appears to be intentional to stop the attack dead in its tracks. Even the error message indicates this behavior:
Request Validation has detected a
potentially dangerous client input
value, and processing of the request
has been aborted.
The only workaround appears to be to disable validation or to capture and handle the error in your global on Application_Error.
It appears that once you define a page to handle specific(or non specific?) errors, it is no longer available directly via its url, sorta like the Web.Config cant be called via the browser.
I would set up a 500Test.aspx which throws an exception causing a 500 error (and thus fires the 500.aspx)
That might work.
You might want to think about handling your errors in the Application_Error event in Global.asax.cs instead of the 500.aspx page. You could put the email code there, then redirect the user to an error page after you've done your error handling (this is how we do it where I work).
Has anyone run into this error message before when using a timer on an ASP.NET page to update a DataGrid every x seconds?
Searching google yielded this blog entry and many more but nothing that seems to apply to me yet.
The full text of the error message below:
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Many issues can cause that error. It's usually a Response.Write call, but anything that modifies the response can cause it.
We probably won't be able to help you unless you post some pertinent code-behind.
The RoleProvider sets a cookie to cache role information in a cookie. When the cookie resets during an asynch post back from AJAX, you will get this error. The solution is to either set the cookieTimeout in the roleManager section of your web.config to a very large number of minutes, or set the cacheRolesInCookie=false.
This was a known bug in AJAX 1.0 Extensions. I'm not sure if it was fixed in future releases, and I should have mentioned that I was using AJAX 1.0 extensions in VS2008 targeting the 2.0 framework.
Happy programming!
Regarding the formatting of your post: If you use the quote-button instead of code-button, people do not have to scroll to see the complete error message.