I read the following advise by dotnetchris in the comments of a blog post by Jonathan Creamer:
In a regular application (aka not a RESTful web service), the proper way to handle a 500 error is to issue a 302 temporary redirect, then redirect to the 500 error page that returns a proper 500 status code.
I would like to know if this advise is correct. My experience as a developer is with ASP.NET MVC, and the error handling approaches I have seen relating to that framework are ones where no redirect is issued for a 500 error.
Generally i cant agree with this approach. It's looks like:
-> Access page that return error -> 302 to other page that return 500 error.
It's mean for search bots that this page redirect to other page that return error due to some result. Of course it's not good in this way. In my app i always show errors on the page where they appear. I just change the template of page in this case.
Related
I am currently building a website and I want to add the HTTP 404 not found Error page. I designed the bad request page and its link is this, for example:
www.mysite.com/badr.cshtml
The problem is, I want to show the contents of this page on every invalid request without redirecting to that link. For example, if I type www.mysite.com/noexistingpage, the contents of badr.cshtml should load without redirecting to it.
And for your information, I am using Webmatrix2.
you do this via the web.config and the custom errors section.
http://www.localwisdom.com/blog/2010/08/how-to-setup-custom-404s-for-iis-and-asp-net-through-web-config/
I'm a noob when it comes to ASP.NET. I know few basic commands such as Response.Redirect("URL") to redirect my application web page to a different location.
However i receive HTTP Error 400 - Bad Request, whenever i try to use the code shown below
Response.Redirect(Server.UrlEncode(this.Downloadlink));
where this.Downloadlink is a user defined property which returns something like this
http://mdn.vatsag.net/fp;files/DOWNLOAD/VTSetup.exe
If i post this link in the browser, the .exe file pops up (means the link is good)
However this error comes when i use the ASP.NET code.
Any form of response on this issue/reason is deeply appreciated.
See here: http://www.kirit.com/Response.Redirect%20and%20encoded%20URIs
In short: if you quickly want to fix the issue, remove the part of your code that is UrlEncoding the URL!
Using forms authentication, is it possible to return a 404 if a user doesn't have access to content, rather than redirecting them somewhere?
I realize I could send them to a 404-ish page, or redirect to a login page that doesn't exist, but I really want to return a 404 from the page they were attempting to access.
Possible?
Better would be to send them to a 403 (Forbidden) page, but still have it look like a normal page from your site.
You should think of customized 404 pages with recommended navigational options when website visitors request pages that return a 404 response code. So I am in support of sending users to a 404-ish page with search options, other navigational links along with a notification that the user has reached a page that does not exist
You are going to have a hard time catching a 403 much less redirect it.
There is a long standing 'bug' in the forms authentication module that simply dumps 'under-authorized' to the registered login page with a 200 OK.
So, not only can you not easily catch a 403 - from my experience 403 has never been a viable candidate for a custom error page. I am not sure why MS has left it in the default web.config for 10 years.
In any case, I have developed a module that will fix this behavior, the code and details can be found here: http://www.codeproject.com/Articles/39062/Salient-Web-Security-AccessControlModule.aspx
The language of the article is tilted towards ajax type requests, but the module is designed with webform based forms authentication in mind as well.
The default configuration will give you the ability to process 403 with a custom error page which can be a simple handler that generates a 404, which will in turn be processed by any custom 404 page you have defined, if any.
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.
So, from here...
In ASP.NET, you have a choice about how to respond to that - it's in the web.config as CustomErrors. Turn that on, then redirect to a fancy 404 page (maybe you already do). The fancy 404 page, then, could be checking the requested querystring (which gets passed over to the custom error page as yet another querystring) to see if it's a valid redirect, lives in your database, etc. Just do a Response.Redirect() from there.
Then schooner writes:
Thanks, we do have a 404 now but we would prefer this not to be detected as a 404 in the process. We would like ot handle it directly and seperately if possible.
..and I'd like to know just how bad a practice this is. I don't expect to put my "pretty" URLs on the internet (just business cards) and I have a sample of 404-redirecting-to-a-helpful-site code working, but I don't want to get to production and have an issue with a browser that takes the initial 404 too seriously. Can anyone help me understand more about why I wouldn't want to use customErrors / 404 to flow users to the page they actually wanted?
The main problem with using customeErrors as your 404 error handler is that every time customErrors picks up an errored request rather than throwing a 404 error back to your browser and letting your browser know there was a bad request, it instead returns a 302 which indicates that a page has been relocated to whatever your customErrors page is. This isn't bad for most users because they don't know or even notice the difference, the problem comes from the fact that web crawlers DO know the difference and the status code they receive directly affects how their indexing works.
Consider the scenario where you have a page at http://mysite.com/MyAwesomePageAboutStuff.aspx for some period of time and then one day you decide you no longer need it and delete the file. If Google or some other crawler has already indexed that URL and goes back to it after you delete it the crawler will get a 302 status code instead of a 404 error and because of this status code the crawler will update the page's url to point to your error page rather deleting the non-existent link. Now, whenever someone finds that url by way of a search engine they'll end up at your error page.
It's not really a huge issue, but you can definitely see the headaches this can create for your users in the long run.
Look here for some corroborating data.
I created a vanity url system using the 404 as the handler. There's no need for a 302 on my side as the 404 dynamically loads the content and returns that. I am fully able to handle any and all POST / GET and SERVER data.
Works great. If you are interested TarantulaHawk is up on SourceForge.