I'm trying out the facebook c# SDK (v4.0.2) and am experiencing a 404 error when facebook tries to redirect back to the redirect handler for the SDK. The resulting URL is:
http://localhost:9152/facebookredirect.axd/elserdemo/Default.aspx?session={%22session_key%22%3A%222.GJsQK_BkApJNH8TncuFHpQ__.3600.1291665600-678938033%22%2C%22uid%22%3A%22678938033%22%2C%22expires%22%3A1291665600%2C%22secret%22%3A%22dnmnVip8JJ31rHUs2byKeQ__%22%2C%22base_domain%22%3A%22localhost%22%2C%22access_token%22%3A%22133477943366316|2.GJsQK_BkApJNH8TncuFHpQ__.3600.1291665600-678938033|xtjv95K4Lj_wg2-X3comNL4haG0%22%2C%22sig%22%3A%2241b1c3884488a9c9fa82b398c7fa80dc%22}
I have the facebook app set to iframe mode for the canvas and the necessary migrations settings in place. I've also made sure the canvas URL points to my local development server. However, when the browser tries to load the URL above, I get a 404 from ASP.NET.
If the pathinfo doesn't contain a period, it works and redirects to my app, so it appears it's the period in "default.aspx" that's screwing things up, but I'm not sure why. Any thoughts? Workarounds?
EDIT:
Although this is an issue with me with the facebook SDK, it's not specific to that. It's apparently an ASP.NET dev server issue. For example, if I try to load:
http://localhost:9152/facebookredirect.axd/elserdemo/default.aspx
I get a 404. However, if I try to load:
http://localhost:9152/facebookredirect.axd/elserdemo/default
It works, but then I end up at a facebook screen with a 404 in the iframe (because default is not a valid in my app).
EDIT #2:
This is not an issue with invalid chars in the URL. If it were, I would be receiving a 400 error code (bad request). Instead, I am receiving 404, which tells me that the dev server is trying to load a file that doesn't exist, rather than stopping at the .axd and passing off the rest as Request.PathInfo like it should. I'm not sure WHY it's doing that, so that's really what I'm looking for here.
Your app is not redirecting to the correct adress. You are getting a serialized version of a FacebookSession object instead of a querystring with a signed_request.
Make sure you are setting the correct values on the facebook app configuration page.
You have to add the redirect handler to your web.config in order for the redirect to work, just add this lines to your web.config
<system.webServer>
<handlers>
<add name="facebookredirect.axd" verb="*" path="facebookredirect.axd"
type="Facebook.Web.FacebookAppRedirectHttpHandler, Facebook.Web" />
</handlers>
Hitting reset on the previous answers.
What, exactly, is telling the browser to go to this URL: http://localhost:9152/facebookredirect.axd/elserdemo/default.aspx
I ask because Facebook should be configured to just go to http://localhost:9152/ and you indicated in the question that this happens when facebook redirects back to your site. The name of the handler shouldn't be in the URL at all which leads me to believe you've misconfigured the app within facebook itself.
Web handlers (like axd's) are executed for every incoming request automatically. If it detects that it needs to do something based on the request stream, then it will.
I got this same error - it turns out that its related to the mimetype mapped by the url's "extension." In your case, the ASP.NET development server is looking for the mimetype ".12916656....", or rather the last period to the end of the url.
If you switch to IIS on your local machine, you can set the default mimetype to application/octet-stream using the wildcard character (details at the link below). However, there's no way to do this in ASP.Net Development server:
http://support.microsoft.com/kb/326965
The 404 error and "File Not Found" exception appears to be how the server handles undefined mimetypes... quite confusing.
Related
I have the following scenario. I have a website in IIS 8 and I am trying to secure it (https). I have made the web with web forms. In the process to secure it I have to change the page at the beginning (default page in the IIS administrator). When I do it, I don't get the change and I go to the website that was set by default.
I have seen the log and when trying to access the new homepage it gives an error 302 (object moved). I have seen the response header and I see that the location is configured with the old home page.
Example:
Old default page: www.namedomain.com/start.aspx
New default page: www. namedomain.com/home.aspx
The new website has as in the response header: location = /start.aspx and as I said before when trying to access it gives error 302.
Thanks.
There's a few things going on here, "securing" the site with HTTPS and also potentially <authentication mode="Forms"> in your web.config where it will try and redirect any unauthorised requests to a login page. It seems like you are just doing the HTTPS though at this stage, and maybe trying to set up a redirect from HTTP to HTTPS?
It sounds like you are also trying to change the default page for the website (in IIS or the web.config?) from default.aspx to home.aspx? I'm not sure I understand why you want to do that as it isn't necessary for HTTPS, but the effect of that will mean you can go to https://www.namedomain.com/ and you will get served the content from home.aspx instead of start.aspx (or default.aspx) but the URL will stay as just https://www.namedomain.com/
Normally to set up HTTPS, all you do is go into IIS, Bindings, and add a HTTPS binding (you'll need a TLS certificate to make the https work properly). then just make sure you include the "https://" at the start of your URL.
If you think it might be caching problem on your machine, just add a nonsense querystring to the end of your URL (like https://www.namedomain.com?blah=blahblah) and it will cause your browser to get a fresh copy of the page.
I'm not sure what is causing the 302 redirect, have you added any special code to swap HTTP requests over to HTTPS? Can you update your answer with any more info?
Yes, it is what I put in my last comment Jalpa. I do not understand very well the relationship between not configuring the session variables and the default page but once corrected in code, the application correctly loads the web by default.
I've tried other solutions (including manually setting the response) but I can't get rid of this message or redirect properly.
Explanation:
I have a hardware that comunicates with my "web api" to register new users.
My web app is running behing a NoIP so every resource that gets accessed in
http://my_public_domain:8082 is forwarded to http://my_internal_domain:80.
That being said, I have to build my routes using the overload of Url.RouteUrl() as I need full qualified routes intead of relative ones.
Url.RouteUrl("MyRoute") generates the route http://my_internal_domain/MyRoute
Url.RouteUrl("MyRoute", dataValues, Request.Url.Scheme, hostName) generates the route http://my_public_domain:8082/MyRoute (notice that I have to change the domain because of the dns)
The problem is that when I try to redirect to that route I get a page with the message Object Moved To Here and a link to that route.
Initially I thought that this problem would happend only with external redirects, but if I just do a Redirect("http://www.google.com.br") for example I don't get this page.
I've tried to manually remove the response html body as sugested in another topic (Response.Redirect results in "Object moved to here") but this do not solve the redirect problem and I only get a blank page.
I've got a bit of an odd situation that recently came up in a security scan and I'm having trouble explaining it. In short, the following URL always returns HTTP 400 and a YSOD:
http://www.mypal4me.com/C:badfile
This site is ASP.NET 4 and is hosted on MaximumASP under IIS7.5. This site is configured with custom errors turned ON and a default redirect page. This is evidenced by causing request validation to throw you off to the error page: http://www.mypal4me.com/?%3Cscript%3E
The only way we've found to send this request off to the custom error page is to add an <error statusCode="400" path="/error.htm" responseMode="ExecuteURL" /> entry under system.webServer.httpErrors in the web.config (obviously this hasn't been done on the site above but has on other MaximumASP sites).
So my question is twofold:
Why is this request not being caught by the usual .NET error handling and the custom error page served as a result?
Why do I only see this happen at MaximumASP - I can't reproduce an HTTP 400 with that pattern in any other IIS/ASP.NET environment.
http://msdn.microsoft.com/en-us/library/s57a598e.aspx
ASP.NET 4 also enables you to configure the characters that are used
by the URL character check. When ASP.NET finds an invalid character in
the path portion of a URL, it rejects the request and issues an HTTP
400 (Bad request) status code. In previous versions of ASP.NET, the
URL character checks were limited to a fixed set of characters. In
ASP.NET 4, you can customize the set of valid characters using the new
requestPathInvalidChars attribute of the httpRuntime configuration
element, as shown in the following example:
It's likely request filtering, specially it doesn't like the C: bit, fearing that it is a directory travesal attack of some sort. Many webhosts security settings will block suck a url.
A most likely guess at the the product in use is UrlScan, http://learn.iis.net/page.aspx/473/using-urlscan
Because this filtering runs at a much lower level in the call chain, the request itself is never passed to your asp.net application process (As many of the attacks that are mitigated are designed to trick IIS into returning files outside your application folder). Thus any application defined error routines won't see it, however an IIS error page (which is what your configuring via webc.config) will be triggered.
Here's the situation: -
I have
<customErrors mode="On" defaultRedirect="error.html" />
in my web.config.
I also have custom error handling code in Application_Error (in global.asax.cs) that checks for certain well known exception types and redirects to custom error pages for each. If the exception is not a well known type then I simple return from Application_Error without calling Server.ClearError() so the default custom handling should take care of showing the page error.html.
But whenever my app throws up an unhandled (and not well known) exception I end up at the default Asp.Net error page - you know the one I mean, the yellow screen of death...
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".
I have checked the obvious stuff (like double checking that I am not throwing another error in Application_Error and I am not accidently' calling ClearError. It is definitely something fishy with this one web app (I made a little test web app and the custom error handling worked as expected) - that should rule out oddities in my machine.config file.
I am going to keep on scratching my head and trying things but in the meantime I thought I would put the question out here to see if anyone had any bright ideas.
PS. I am working on Windows 7 Business (IIS 7.5) but the same behavior is observed on Win server 2003 (IIS6).
Thanks Joe and Click for having a look but this problem is all my fault!
One crucial bit of information that I omitted from the description is that my web page flushes the response before the request is finished (see * below if you want to know why I do this nastiness).
It seems that once some content has been sent to the client, the customError handling no longer works. I can't say that this is a failing of the custom error handling because it would probably take some dark voodoo to tell a browser to redirect to once it had started rendering content!
Having said that I was hopeful that adding redirectMode="ResponseRewrite" to the customError node would help (maybe get the error page below the content I have already sent to the browser?) but that fails too. Nevermind.
A quick google yields this http://forums.iis.net/p/993221/1313916.aspx - and a chap on there has a work around that I will try. The technique suggested in http://forums.iis.net/p/993221/1399583.aspx#1399583 works. It is far from ideal (we have to read the web config) but it works.
(*) why am I flushing the response before the request is finished? Some of our pages return large reports which can take several seconds to generate. We send a "PLease wait + spinny gif" message to the clients at the start of these requests and flush that so that the browser renders the message + icon whilst it waits for the rest of the response. I think I shall investigate a less "hacky" way of achieving this.
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.