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.
Related
After analyzing the web, to see SEO failures, I see that I have a page that returns a 403 but it is shown as any other page.
The web is in Drupal, and I verified that it was not a block that was added with blocked permissions.
I do not see why it returns 403.
Probably you have 403 page configured under /admin/config/system/site-information:
The whole thing started when I noticed Facebook Debugger and other crawler tools are unable to parse my page. Facebook throws a critical error saying that it cannot follow the redirect. I believe Search Engine bots are hitting the same end. The website is functioning normally via all major web browsers.
It's probably worth to mention I am experimenting with ASP.NET Routing, using Web Forms under IIS8.
Given a website (http://example.com), here's what happens.
Case 1: Trying to access the root, this is what I get with a Web Sniffer simulator
Case 1 observations:
First thing I notice is '302' redirect instead of '200 OK'. It gives a 302 redirect with or without leading 'www'.
I noticed is that the Location Header is simply "/", confirmed by the page from IIS that I cannot see with a regular browser, which says the page is moved to "/". I believe something messes up at this point and the crawler is unable to follow through for some reason.
Case 2: Trying to access a given category page with a Web Sniffer simulator
Case 2 observations:
As you might figured out already, identical to case 1. And once again Facebook debugger cannot go through it, resulting to a redirect it cannot follow.
Questions:
1: How can I force an absolute path in the location headers instead of relative and will this be sufficient for the crawlers to follow through?
2: What could cause a 302 redirect happening in the first place in both www and non-www versions of the website?
Your web application is most likely depending on a cookie. The application sends a Set-Cookie header and redirects to the same page in order to receive a new request with the cookie data available. Search engines / bots, the Facebook bot and your Web Sniffer simulator will not send that cookie data and hence the web application keeps sending the 302 redirect responses.
The solution is to change your application to not require cookies for just simply viewing your web pages.
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 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.
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.