Possible Ways to Communicate Between iFrame and Parent Page across domains - javascript

Please suggest possible techniques to trigger events in parent page from an iFrame. I tried out url Hashing and using window.postMessage techniques but without any success.

easyXDM is designed for this exact purpose.
You can find it at http://easyxdm.net and it has quite a few examples.
To sum it up, it allows two windows to communicate 'freely' using either strings or RPC calls.
See http://consumer.easyxdm.net/current/example/methods.html for one of the RPC-demos.

No success because you cannot for security reasons.

The modern answer to this question is the new cross-document messaging (Web Messaging API)
See Opera's introduction here:
http://dev.opera.com/articles/view/window-postmessage-messagechannel/
Or the specification here: http://www.w3.org/TR/webmessaging/

The only idea that comes to mind is to have a script on server side that the iFrame sends its events to (combined with a unique ID) and that the parent page can poll (either through a server script on its domain, or JSONP). That's a lot of work to do, though, and requires cooperation from both the parent page and the iframe.

Related

Cross-domain, cross-tab communication between co-operating pages

Say I have two tabs, each with a web-page loaded on a different domain. The pages in the two tabs want to communicate.
The simplest solution I could see was this one (my answer on a closely-related question I found while searching for duplicates), where one or both of the pages load an intermediate page iFrame, which proxies between postMessage() and localStorage events. However, this does require this page to be hosted somewhere, and an extra request by the client.
Are there any techniques for this that wouldn't require a specialised "proxy page" to be served by one of the domains? (I.e. that could be implemented by a JavaScript library without a supporting server?)
This javascript library appears to provide the functionality you're looking for (i.e., supports cross-origin communication between browser tabs). I have not used this yet, but will be trying this out in my application. Check out https://github.com/wingify/across-tabs.
I'd probably chose to create a backend API service as a common communication tunnel between the 2 different websites.
Eg.
Site-A send a POST message to https://your-API-service
When Site-B asks for an update to https://your-API-service
Then API service returns the message previously sent from Site-A
If you need real-time communication you can also use WebSockets or push notifications
The window.PostMessage API is what you're looking for.
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
The window.postMessage() method safely enables cross-origin communication between Window objects; e.g., between a page and a pop-up that it spawned, or between a page and an iframe embedded within it.

Explicitly allowing cross-domain iFrame scripting for an SDK

I'm beginning to develop a JavaScript client SDK that adds an iFrame to the DOM. The URL of the iFrame is on my domain, but the SDK is going to be used on third party domains. What is a reliable, cross platform, degradable method of allowing my client SDK to manipulate the iFrame? I want to allow the people implementing my SDK to have a set of functions to call and events to subscribe to which originate from the iFrame.
Facebook seems to do a really good job of this in their Apps & Pages system. Usually in that case, though, you're calling out from within a frame. Mine is bidirectional.
I found a great blog post detailing an older method of accomplishing this. It also links to several libraries that implement the various methods.
Porthole
XSSInterface
EasyXDM
jQuery PostMessage Plugin
Why don't you look into JSONP instead? It's JSON with Padding and allows cross-domain requests. I'm only thinking that iframes are so passé.
You have the problem with cross-domain policy. If you have it in another domain you don't have to have iframe. Use a webservice or simply send POST or GET messages to a URL.

Cross-Origin resource sharing and file://

I am writing an HTML5 application that is gathering data from a few different sources using JSONP. Anything I'm doing with a GET works perfectly. I'm now trying to POST data, and I've run into an interesting snag. I need to POST data from my application to another, where my application is running from a local machine. I am trying to write a cross-platform capable mobile application (think Pulse/Flipboard), so the code will always be running from a local source. My thought process was as follows:
Use JSONP - JSONP does not allow for posting, it just doesn't work that way (Post data to JsonP)
Rely on CORS - Since the request is coming from a local source using file://, the origin header is null. This causes the request to fail (XmlHttpRequest error: Origin null is not allowed by Access-Control-Allow-Origin)
Use another server to bounce the request off of - this would be expensive
All of the browsers I'm targeting are webkit based (iPad, Playbook, Android), so I'm wondering if there are any creaks in the same origin policy code that I can sneak through? Maybe something using iframe or postMessage?
As it would turn out, the easiest way to do this is to post to the target url inside of an iframe. Same origin policy on most browsers allows you to perform an HTTP POST from one domain to another unrelated domain. I solved the problem by adding an iframe to my page, initially set to a local bootstrapping page. Since that page was loaded from the same domain, I am able to control it via script. I used that to post the form to my target site, and polled the results to determine if my call was successful. It's not elegant, but it works.
This Javascript library can almost certainly help you:
http://easyxdm.net/
easyXDM is a Javascript library that
enables you as a developer to easily
work around the limitation set in
place by the Same Origin Policy, in
turn making it easy to communicate and
expose javascript API’s across domain
boundaries.
..
At the core easyXDM provides a
transport stack capable of passing
string based messages between two
windows, a consumer (the main
document) and a provider (a document
included using an iframe). It does
this by using one of several available
techniques, always selecting the most
efficient one for the current browser.
For all implementations the transport
stack offers bi-directionality,
reliability, queueing and
sender-verification.

Avoid x-domain solutions

I'm currently working on a web application that customers can add to their webpages by adding a javascript link to a js file on my server. The application read all the javascriptfiles from my sever, but I still get an error when trying to use ajax to get data from my database. I didn't think that would be a problem because the files is on my server.
Can I fix this or do I have to make a cross-browser solution? I don't have any control over the costumers server.
Thanks in advance
Mikael
This is not possible: When you execute a remote script, it runs in the context of the containing document.
There are some popular workarounds for this:
Using an iframe, which fixes the cross-domain problem but doesn't integrate well with the remote site (e.g. no custom styling)
Using JSONP to make cross-domain Ajax requests (detailed explanation here)
Using a server-side proxy script (not an option in this scenario)
Using YQL (I'm not familiar with this but it's said to work)
The same origin policy is based on the host document not the script itself.
You need to use a cross domain ajax technique.

how facebook does cross domain ajax call?

I am looking forward to create a javascript API that contains most of the functions that facebook Javascript API provides.
FB.api
FB.init
FB.logout
FB.getLoginStatus
FB.login
FB.ui
I can just embed script tag in remote website and need to do all the ajax calls from that page to my server. I am creating an architecture and needs someone help in finishing it with his/her excellent ideas.
Take a look at https://github.com/facebook/facebook-js-sdk/blob/deprecated/src/core/xd.js
They use a combination of rpc workarounds (with a relay file), Flash Local Connection and postMessage, whichever is supported by the browser.
You can also take a look at Cross Site XmlHttpRequest(CORS). From your question, it seems that you can control your server that will respond to the requests. In that case, you can tune the headers to receive requests and respond to cross domain requests.
Then, your embedded script will be able to talk to your server from any web page if you configure the request header in the requests that you make from your embedded script.
I like this method as it is extremely easy to implement. Watch out for browser support though!
They are using JSONP. It's widely used and is supported by javascript frameworks like JQuery.

Categories