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.
Related
Is there any way in javascript to check if the browsing is happening on the same page tab in the same window or is it happening in different window? If not in javascript, by communicating with the backend built using java
This might answer you partially.
You can listen for visibilitychange event of document. This event would be fired when you switch browser tabs or windows.
Nice exmaple from MDN
If you have a web application in different windows (be it in one browser or in another browser) then those client applications interact with the server by sending http requests.
Your server can look at those requests and per se will only see the IP address, which is not enough information to differentiate different browser windows on that machine.
So you have to add that information.
E.g. you could send a bit of information (a token), e.g. a unique number to the client in one of the early http exchanges and insist that the client application puts its token into every of its requests. This establishes a primitive session, meaning you can group (and identify!) various http requests together.
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.
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.
using JavaScript, it is much needed to get some pages from the web using without actually moving from the current page and hidden from the user's eyes.
To request a web page without showing it to the user, it is easy to use XMLHttpRequest but it has its own limitations most importantly it does not retrieve cross-domain pages very well. For security reasons the browsers (Mozilla FireFox 3.6+ in my case) retrieve a header from the target site and if the referrer's location is allowed access in that header, only then will the browser continue getting the target web page and JavaScript can only then parse the retrieved info.
This causes the XMLHttpRequest to work with some pages and not work with others if you are trying to access cross-domain pages. Of course it works well if you need to retrieve the information from the same location as the referrer page where the XMLHttpRequest is located.
This is a big problem, when security is not really no 1 priority. For example, imagine writing a script for retrieving live data from a statistics-producing web site or imagine a bot that needs to retrieve data from an online gaming web-site.
Now, how can JavaScript be used to get pages from other domains (cross-domain reference)?
I thought maybe we could find a plug-in that does the job (of course after installation upon user's permission) and then use its properties by JS and eliminate the need for XMLHttpRequest. Do you know any such plug-in or another roundabout for this problem? (ie get cross-domain data by JS without XMLHttpRequest) of course we cannot use XMLHttpRequest as we don't have any control over the target page headers and we obviously want to hide the whole process from the user
You’ll find that it’s the priority that the target site puts on their own security that is most important. If they're unconcerned about JavaScript on other sites accessing their site, they can set the HTTP Access Control headers for cross-domain XMLHTTPRequest, provide a crossdomain.xml file for Flash, provide a JSONP API, or provide some hooks for iframe monitoring.
The second solution is to make the requests to a server on your domain which proxies the request to the target site. In certain circumstances you may be able to use a third party server which supports cross-domain or JSONP requests, like Yahoo! Pipes.
If neither of these is feasible, you'll need to convince the user to allow you to run your own code on their PC. This could be via a signed Java applet which requests special permissions, or your own custom browser plugins or extensions.
There are several ways including using JSONP with XMLHttpRequest, using Flash and using iframes.
Here is some information on this subject. http://snook.ca/archives/javascript/cross_domain_aj
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.