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.
Related
I have a comment form on my website and I would like to stop any HTML from being posted through it. I was under the impression that ASP.NET automatically stops any HTML from being submitted by throwing a "potentially dangerous request" exception, but it's allowing HTML in this case.
All of the settings that relate to validation have been left to default so it should be set to requestValidationMode="4.0".
Anyone know what can cause this? Does it have anything to do with the fact that I am using AJAX callbacks?
Edit: I have gathered some more details:
Validation is correctly working in one sub-folder in my application, but it isn't working in any of the others. I looked into my web.config and this is the only setting I have put regarding page validation:
<pages enableViewStateMac="true" validateRequest="true">
Why is it working in one subfolder but not in the others? Does it have anything to do with the fact that this subfolder has a web.config entry regarding authentication?
Edit: Regular postbacks are being validated, just not callbacks.
Edit again: I was playing around with Fiddler and while doing so I noticed one of the callbacks was blocked by the server. Here is what the blocked request looks like:
And here is the plain text version:
__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUKLTI4MDgzMDI5NA9kFgJmD2QWBAIBDxYCHgdwcm9maWxlBSFodHRwOi8vd3d3LnczLm9yZy8yMDA1LzEwL3Byb2ZpbGVkAgMPZBYOZg8WAh4Fc3R5bGUFkAFiYWNrZ3JvdW5kLXBvc2l0aW9uOnJpZ2h0IGJvdHRvbTtiYWNrZ3JvdW5kLXJlcGVhdDpOby1SZXBlYXQ7YmFja2dyb3VuZC1pbWFnZTp1cmwoaHR0cDovL2xvY2FsaG9zdDo4MS9JbWFnZXMvTGF5b3V0LUltYWdlcy9UaXRsZUJhY2tncm91bmQucG5nKTtkAgIPFgIeCWlubmVyaHRtbAWlAjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij48IS0tCmdvb2dsZV9hZF9jbGllbnQgPSAiY2EtcHViLTk2MTM2OTA0OTA1Mjg4MTQiOwovKiBCT0lHIFRvcCAqLwpnb29nbGVfYWRfc2xvdCA9ICI0MjcwOTc3NjY2IjsKZ29vZ2xlX2FkX3dpZHRoID0gNzI4Owpnb29nbGVfYWRfaGVpZ2h0ID0gMTU7Ci8vLS0%2BCjwvc2NyaXB0Pgo8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCIKc3JjPSJodHRwOi8vcGFnZWFkMi5nb29nbGVzeW5kaWNhdGlvbi5jb20vcGFnZWFkL3Nob3dfYWRzLmpzIj4KPC9zY3JpcHQ%2BZAIDDxYCHwIFqgI8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI%2BPCEtLQpnb29nbGVfYWRfY2xpZW50ID0gImNhLXB1Yi05NjEzNjkwNDkwNTI4ODE0IjsKLyogQk9JRyBTaWRlYmFyICovCmdvb2dsZV9hZF9zbG90ID0gIjIyMDAxMDYxMTAiOwpnb29nbGVfYWRfd2lkdGggPSAxNjA7Cmdvb2dsZV9hZF9oZWlnaHQgPSA2MDA7Ci8vLS0%2BCjwvc2NyaXB0Pgo8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCIKc3JjPSJodHRwOi8vcGFnZWFkMi5nb29nbGVzeW5kaWNhdGlvbi5jb20vcGFnZWFkL3Nob3dfYWRzLmpzIj4KPC9zY3JpcHQ%2BZAIEDw8WAh4HVmlzaWJsZWdkZAIFDxYCHwIFEjxwPkxpbmsgMSB0ZXh0PC9wPmQCBg9kFgICAw8WAh8DaGQCBw8WAh4EVGV4dAU%2BPHNwYW4gc3R5bGU9Im1hcmdpbi1yaWdodDogNXB4OyI%2BwqkgQmluZGluZ09mSXNhYWNHdWlkZTwvc3Bhbj5kZKMbP1fMlxWhgVw8zpEPBPGzlw5j&=sdfdsgd%40sfds.com&=%3Cp%3Efghfghfg%3C%2Fp%3E&=%3Cp%3Efghfghfg%3C%2Fp%3E&=%3Cp%3Efghfghfg%3C%2Fp%3E&__CALLBACKID=__Page&__CALLBACKPARAM=sdfdsgd%40sfds.com--%7C%7C--%3Cp%3Efghfghfg%3C%2Fp%3E--%7C%7C--%3Cp%3Efghfghfg%3C%2Fp%3E--%7C%7C--%3Cp%3Efghfghfg%3C%2Fp%3E
Here is a typical request that isn't blocked:
Plain text:
__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwUKLTI4MDgzMDI5NA9kFgJmD2QWBAIBDxYCHgdwcm9maWxlBSFodHRwOi8vd3d3LnczLm9yZy8yMDA1LzEwL3Byb2ZpbGVkAgMPZBYOZg8WAh4Fc3R5bGUFkAFiYWNrZ3JvdW5kLXBvc2l0aW9uOnJpZ2h0IGJvdHRvbTtiYWNrZ3JvdW5kLXJlcGVhdDpOby1SZXBlYXQ7YmFja2dyb3VuZC1pbWFnZTp1cmwoaHR0cDovL2xvY2FsaG9zdDo4MS9JbWFnZXMvTGF5b3V0LUltYWdlcy9UaXRsZUJhY2tncm91bmQucG5nKTtkAgIPFgIeCWlubmVyaHRtbAWlAjxzY3JpcHQgdHlwZT0idGV4dC9qYXZhc2NyaXB0Ij48IS0tCmdvb2dsZV9hZF9jbGllbnQgPSAiY2EtcHViLTk2MTM2OTA0OTA1Mjg4MTQiOwovKiBCT0lHIFRvcCAqLwpnb29nbGVfYWRfc2xvdCA9ICI0MjcwOTc3NjY2IjsKZ29vZ2xlX2FkX3dpZHRoID0gNzI4Owpnb29nbGVfYWRfaGVpZ2h0ID0gMTU7Ci8vLS0%2BCjwvc2NyaXB0Pgo8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCIKc3JjPSJodHRwOi8vcGFnZWFkMi5nb29nbGVzeW5kaWNhdGlvbi5jb20vcGFnZWFkL3Nob3dfYWRzLmpzIj4KPC9zY3JpcHQ%2BZAIDDxYCHwIFqgI8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCI%2BPCEtLQpnb29nbGVfYWRfY2xpZW50ID0gImNhLXB1Yi05NjEzNjkwNDkwNTI4ODE0IjsKLyogQk9JRyBTaWRlYmFyICovCmdvb2dsZV9hZF9zbG90ID0gIjIyMDAxMDYxMTAiOwpnb29nbGVfYWRfd2lkdGggPSAxNjA7Cmdvb2dsZV9hZF9oZWlnaHQgPSA2MDA7Ci8vLS0%2BCjwvc2NyaXB0Pgo8c2NyaXB0IHR5cGU9InRleHQvamF2YXNjcmlwdCIKc3JjPSJodHRwOi8vcGFnZWFkMi5nb29nbGVzeW5kaWNhdGlvbi5jb20vcGFnZWFkL3Nob3dfYWRzLmpzIj4KPC9zY3JpcHQ%2BZAIEDw8WAh4HVmlzaWJsZWdkZAIFDxYCHwIFEjxwPkxpbmsgNSB0ZXh0PC9wPmQCBg9kFgICAw8WAh8DaGQCBw8WAh4EVGV4dAU%2BPHNwYW4gc3R5bGU9Im1hcmdpbi1yaWdodDogNXB4OyI%2BwqkgQmluZGluZ09mSXNhYWNHdWlkZTwvc3Bhbj5kZCu6t45MzsFLBRWYDAvPXYbIXKqE&=&=&=&=&__CALLBACKID=__Page&__CALLBACKPARAM=cfdsdg%40adfds.com--%7C%7C--%3Cp%3Esdfdgdfg%3C%2Fp%3E--%7C%7C--%3Cp%3Esdfdgdfg%3C%2Fp%3E--%7C%7C--%3Cp%3Esdfdgdfg%3C%2Fp%3E
I don't know why the requests are different, nothing changed on the page. I noticed that the first one seems to have split the parameters into the boxes while the second one hasn't. Is this the issue?
I just checked the callbacks being sent from the sub-folder and they are all split into parameters just like the first request. I guess this is the problem... but why is it happening?
I made the inputs runat=server and the request changed a bit, but the values are still not being assigned.
Here is what I found:
___CALLBACKPARAM is not actually validated by the server, only the parameters as seen in the first image are. With this in mind I validated the request myself using the following regex <\/*(p|div|span|a|script|br|b|i|u|h1|h2|h3|ol|ul|li)\s*.*>. You can find more online; hope this helps.
I have read a lot about this error message.
I've learned that the most common causes for this error are
when the response is modifed by calls to Response.Write(), response filters, HttpModules
server trace is enabled.
There are some suggestions like to use a web debugger (ie. Fiddler) to get the server's response, set the EnableEventValidation="false" to the page that this error came up, set the cookie timeout and the likes.
My question, is there any other way to avoid this like doing something on the settings of the browser?
What is the point in hiding the error altering the browser settings? Your end user would still get that error as you wont be able to change their browser settings.
The key to the answer is in your question itself. You find out what is causing the error and then rectify it.
Useful read: Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it
I have a website project, that is working fine. However every once a while certain ajax pages (that make calls to a webservice) throw a "the server method xxx failed". I have ELMAH installed, however do not see any stacktrace or anything. The worst is that I can not reproduce the error locally. I just get an email notification from ELMAH. Does anybody know how I can fix this issue?
Edit: After 1 year I am still having the same issue.
It's too insufficient description. My assumptions:
Did you add EnablePageMethods
="true" to your ScriptManager control?
If yes, did the control (if it is; e.g. button) which call the web service method perform an anync postback instead of full one?
Does the signature of server method
and a call from the client-side
match?
Are you using URL rewriting?
I had the same issue and found my application firewall was blocking the content-type 'application/json'. Check if you have anything running on the web server that could be blocking the page method.
I happened the same with ASP.NET, remove the property runat="server" and run success
I’ve had a bit of feedback from some threat and vulnerability folks relating to websites returning HTTP 500 response codes. Essentially the advice is that all possible measures must be taken to avoid the server throwing a 500 (i.e. extensive form input validation) which is fine.
However, the advice also suggested that attempts to compromise security by means such as inserting a tag into a random query string causing ASP.NET request validation to fire or manipulating viewstate also should not return an HTTP 500. Obviously the native framework behaviour is to interpret the request and possibly throw to a custom error page but even this will return a 500 response code.
So I’m after some thoughts on how to approach this. Is there any way to configure the app at either the .NET level or IIS level to return an HTTP 200 when a 500 is raised? Or does this become a coding exercise at global.asax level in one of the application events? Are there other consequences to consider?
BTW, the rationale from the security side is that apps which return HTTP 500 may be viewed as “low hanging fruit” by bots randomly scanning for vulnerabilities and prompt further malicious activity. attempts I’m personally not convinced that changing response codes offers any real security gains but am happy to hapy to take the advice of the pros.
To answer your question: global.asax is the correct place, in particular, the Application_Error event handler. You should be able to do something like
Response.StatusCode = 200
Response.StatusDescription = "OK"
there.
PS: Don't do it. :-) To me, this sounds like yet another security-by-obscurity-by-violating-standards approach. I really don't think the (possibly marginal) security increase is worth breaking correct HTTP behavior (think about Google indexing your error pages, etc.).
Why? Sending back a 500 code without any other information does not give an attacker much information.
Provided you don't throw stack trace, state dumps etc, back to the client then you're fine. And I doubt very much you want to do that.
Seriously, just create a "500" page (picture of a whale optional) and return that with your status 500 - it gives nothing away.
Sending a 200 status when the page was NOT generated successfully is plain wrong and may cause bad things to happen - such as bots thinking it is a genuine page. You don't want your "500 error" page showing up on Google because you sent back a 200 status instead.
You can set custom error pages in config - and you could re-set the response status in your custom error page
<customErrors mode="On" defaultRedirect="~/DefaultErrorPage.htm" >
<error statusCode="500" redirect="~/CustomError.aspx"/>
</customErrors>
Serious warning...!
Make sure there aren't any errors EVER in your custom error page. Usually, you would use a html page, not an aspx page - but if you want to change the response headers you may need to use the aspx page. Don't do anything else on there except change the headers (i.e. don't display any data from a database or try to run any logic) and error on your custom error page will cause a "maximum number of redirects" error.
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).