I'm working on a Facebook Canvas App, and which by definition loads the code/webpage for my app in an iFrame on the Facebook website.
During development I have got the impression that if I make an AJAX request from my App's webpage to a webservice for my app which is on exactly the same server/domain name as the webpage, that that is actually technically a cross domain request - because the page originally loaded in the (top) frame of the browser is on a different domain to my webservice.
However I now believe that, due perhaps to a bug in my code, I was mistaken, and a page in an iFrame can make requests to URLs on the same domain as it without being a cross domain requests.
Clarifying this is particularly important to me as I now believe I can actually use POST requests instead of having to use JSONP GET requests.
If someone could clarify this for me I would greatly appreciate it. I have search around and cannot find a clear statement on this scenario.
EDIT: To provide more clarification: my Facebook App page URL at https://apps.facebook.com/myapp/ loads my webpage at www.mydomain.com in an iFrame. The webpage at www.mydomain.com then makes an AJAX request to a webservice on www.mydomain.com (at eg. www.mydomain.com/webservice/). So is the request from my webpage to my webservice a Cross Domain request or not?
Cheers
Matt
Your document loaded within the iframe is still a document of it’s own, and behaves like any other document, whether it be displayed in a frame or not, when it comes to the same origin policy.
So yes, you can absolutely make AJAX requests to the domain that your document got delivered from, not matter that it is displayed inside an iframe on Facebook.com.
There is no crossing of domain boundaries involved.
Related
Many (probably the majority) of AJAX calls are done by a browser on a webpage and that webpage has a URL. Is it possible for a webserver to that's receiving the AJAX request to determine the URL of the webpage where the AJAX call was made? I assume there isn't a standard that requires this data in the headers, but perhaps some browsers include that info? Obviously this doesn't apply if the AJAX call was made from a phone app or other application without a URL.
Very generically (though unreliable), check incoming request headers for Referer. That should give you information about the source page.
Just keep in mind it can be spoofed, absent, etc. and shouldn't be considered bullet-proof (though it doesn't sound like you need it to be anyways).
I'm using a website, abc.com, that is hosting an iframe of a page on 123.com.
The page inside the iframe is doing an AJAX request to another page on 123.com, but we're seeing that the request is getting cancelled.
Unless I'm wrong — and I haven't found any official information on the internet about this — the call should work fine as it is not a cross-domain request.
Would the fact that the parent frame is on a different domain really hinder the iframe from doing AJAX requests to its own server?
The IFRAME should be able to make an ajax request to its own originating site (same source URL). However, make sure the REQUEST event is FIRED from the IFRAME, not the parent.
My first guess would be you are loading the IFRAME and then addressing it (firing an event) via the parent (JS) to get it to do/get/set something which triggers an ajax call. In short, this is the mostly likely reason the IFRAME domain to same domain request is getting cancelled as it is still recognized by the browser as originating from outside the target domain code.
The REQUEST event needs to be organically generated from the user clicking on something in the IFRAME or from code in the IFRAME itself firing the event.
In other words: just because the IFRAME may have some ability to fire events/ajax in its JS/code to/from itself, it would normally still not be allowed to have the parent reference that ajax/JS directly via JS/code. The IFRAME has to already be coded to do it based on its load parameters (URL values, perhaps) or the user has to physically click/take action on something to create a user generated event on that domain.
Of course, this is going to vary a bit by browser and version on what you might be able coax in terms interactivity between the parent and iframe. But a strict, up-to-date browser will try to keep you from faking insecure interaction on the iFrame via js.
To get a better answer, you would need to provide more detail on exactly what you are doing/getting.
Problem:
A part of a web application contains another web application from another domain.
Both web applications make AJAX requests to the domains they originated from which poses problems because of the same origin policy for AJAX requests.
Solution:
One way to achieve this is to wrap the contained web application in an iFrame. The AJAX requests in it go to the the same domain of the iFrame - which is different from the parent application.
This sounds fine to me, but since iFrames ae unfashionable, what other / better way is there to do this?
Are you not able to have both applications send an AJAX request to your domain, and have your server side perform the call to a foreign domain, and then relay the result it receives back to the requesting client side App. Your server in essence becomes a proxy for the AJAX request?
What do you men unfashionable? If you like to hind you can apply height to 0 and display none.
Given all the coverage FireSheep has been getting, I have been trying to work out the best practices for balancing HTTP / HTTPS usage for some sites I manage (e.g. blogging sites, magazine sites with user contributed comments).
To me, its over kill to deliver all pages over HTTPS if the user is logged in. If a page is public (e.g. a blog) there is little point encrypting the public page. All I want to do is prevent session hijacking by sniffing cookies over HTTP channels.
So, one plan is:
Login form is over HTTPS
Issue two cookies: One cookie is 'public' and identifies there user for read only aspects (e.g. 'welcome bob!'). The second cookie is private and 'HTTPS only'. This is the cookie that is verified whenever the user makes a change (e.g. adds a comment, deletes a post).
This means that all 'changing' requests must be issued over HTTPS.
We use a lot of AJAX. Indeed, many comment forms use AJAX to post the content.
Obviously, I cant use AJAX directly to post content to a HTTPS backend from a HTTP frontend.
My question is: Can I use script injection (I think this is commonly called 'JSONP'?) to access the API? So in this case there would be a HTTP public page that sends data to the private backend by injecting a script accessed via HTTPS (so that the private cookie is visible in the request).
Can you have HTTPS content inside a HTTP page? I know you get warnings the other way around, but I figure that HTTPS inside HTTP is not a security breach.
Would that work? It seems to work in chrome and FF, but its IE that would be the party pooper!
Another way is to have an iframe which points to a https page that can make all kinds (GET, POST, PUT etc) of Ajax calls to the server over https (same domain as iframe is on https too). Once the response is back inside the iframe, you can post a message back to the main window using HTML5 postMessage API.
Pseudo code:
<iframe src="https://<hostname>/sslProxy">
sslProxy:
MakeAjaxyCall('GET', 'https://<hostname>/endpoint', function (response) {
top.postMessage(response, domain);
});
This works in all modern browsers except IE <= 7 for which you'll have to either resort to JSONP or cross domain communication using Flash.
The problem with JSONP is that you can only use it for GETs.
Can you have HTTPS content inside a
HTTP page? I know you get warnings the
other way around, but I figure that
HTTPS inside HTTP is not a security
breach.breach.
Including HTTPS content inside a regular HTTP page won't raise any alerts in any browser.
However, I don't think JSONP will help you out of this one. Using GETs to post content and modify data is a very bad idea, and prone to other attacks like CSFR
When a certain machine tries to access my website, all AJAX calls fail. This happens for all browers on this machine, and no firewall or anything of the sort seems to be enabled. What could be the issue here? Opera tells me that the AJAX calls are returning a SecurityException.
What could POSSIBLY be happening to cause this one machine to fail on AJAX calls?
Do not use the full URL of your website in AJAX calls.
For example, suppose
http://example.com and http://www.example.com point to the same resource. If you give your AJAX calls the URL www.example.com/ajax.do, your calls will fail if the user browses the site from the first location.
Could it be that your site requires a login, and the AJAX Calls are not carrying over the session, for example because the browser has cookies disabled?
You may also want to post some more information about the site in question and whether that machine can access normal web pages on your site.