I have a web app in http://domain1/app1/called.html, and I want to embed that application inside http://domain2/app2/caller.html with an iframe (or a popup, it's the same)
the user should be able to interact with called.html, until they press a certain button, in that case I need to tell caller.html that the user selected an item from called.html
I tried implementing it with javascript.
in called.html I encode the data in json, and then I execute a "called_callback" javascript function in caller.html, passing the json as a parameter.
if called.html was called with a popup, I issue window.opener.called_callback( jsonData ), if it's an iframe I just issue parent.called_callback( jsonData )
having caller.html and called.html in the same domain everything works fine, but from different domains I get the following errors:
permission denied (on IE6)
and
Unsafe JavaScript attempt to access frame with URL [..]/caller.html from frame with URL [...]called.html. Domains, protocols and ports must match. (on google chrome)
Is it possible to overcome this limitation?
What other way of achieving it can you think of???
I guess caller.html could implement a web service, and I could send the result calling it, but the page caller.html would have to poll in order to detect any change...
So how can one application communicate with another one in a different domain to signal an event???
You can use JSONP to call resources from one domain to another.
You can use window.name as ~2Mb text transfer between cross domain frames for older browser.
Or for modern browser you can use window.postMessage to communicate string data between the 2 frames.
But you need some cooperation from the domains for these techniques to work.
You should look into using JSONP. It is fully supported in jQuery if you are using that particular framework. It allows you to use JSON across domains.
Thanks to both answer I found the following:
http://benalman.com/code/projects/jquery-postmessage/docs/files/jquery-ba-postmessage-js.html
http://benalman.com/projects/jquery-postmessage-plugin/
jQuery postMessage enables simple and
easy window.postMessage communication
in browsers that support it (FF3,
Safari 4, IE8), while falling back to
a document.location.hash communication
method for all other browsers (IE6,
IE7, Opera).
With the addition of the
window.postMessage method, JavaScript
finally has a fantastic means for
cross-domain frame communication.
Unfortunately, this method isn’t
supported in all browsers. One example
where this plugin is useful is when a
child Iframe needs to tell its parent
that its contents have resized.
I'll have a look at it...
here's a very complete document that analizes the different approaches...
http://softwareas.com/cross-domain-communication-with-iframes
another solution to have a look at
http://easyxdm.net/
with a sample
http://easyxdm.net/wp/2010/03/17/setting-up-your-first-socket/
Related
Is it possible to get around the security and mimick either a full-browser or mobile browser within a webpage?
I had an idea to set the HTML manually, using an AJAX/XMLHttpRequest ("Get" request)
document.querySelector('#myiframe').contentWindow.document.write("<html><body>Hello
world</body></html>");
(from How to set HTML content into an iframe)
Can anyone verify this is possible? I'm guessing you would lose relevant site date (cookies, cache, etc)
Is it possible to get around the security
Yes, many browsers let you start them in a security-off mode, e.g. on chrome you run the program with the --disable-web-security flag. However, you should never ask a client to do this.
An alternative way would be to write a Java applet, or some other third-party plugin, which fetches the resources you want and then passes it over to the browser with your favourite method, from which you can use JavaScript on the data as desired. This method would lose things like cookies, and might be exploitable so I wouldn't recommend it.
mimick either a full-browser or mobile browser within a webpage?
Finally, if you don't mind the "URL bar" displaying the wrong thing when a user navigates, you could just use the default behaviour. This method is totally acceptable and doesn't circumvent any security.
It's possible with
$('#iframe_id').contents().find('.stuff_to_modify).addClass('whatever');
But it's also possible using window.postMessage events, by sending a do_something message to a script from the iframe, which does the modifications when the message is received (adds that class).
I was wondering which is the way I should go, and what are the differences between these two methods (drawbacks, advantages).
The jQuery method seems nicer because I don't need to include any script in my iframe anymore
The major difference between window.postMessage and jQuery sample you gave is that, postMessage enables cross-origin communication.
Meaning, if a Parent page which hosts the iframe is from domain A, while the content of the iframe is from domain B, then postMessage allows you to communicate while the jQuery approach will result in the security error.
The link you provided is a java script wrapper to window.postMessage implementation of the browser and falls back to window location hash polling for browsers that do not support it. Other benefits are listed in your link itself.
So, if the two pages are from same origin, i.e served from same domain, then you can go the jQuery approach itself. If it is from two different origins, you may have to use the JS wrapper.
First of all - I have read teens of SO similar questions and other googled pages / blogs.
There was many ways to make cross-domain communication work, but is there something that lets me do that, when I'm unable to modify page (for example http://www.imdbapi.com/?t=True%20Grit&y=1969 ) that I want call?
Can I use postMessage solution (this method looked best to me) without ANY modification in http://www.imdbapi.com/?t=True%20Grit&y=1969 ? It looks like it has no helper page (one of the methods).
I don't want to use any 3rd party library / php script / etc - just pure html and javascript - is it possible to call such a 'immutable' page? ... and parse it on my own page (simple iframe is ofc not enough)
Please help - my huge research leave me with nothing
ok, here's the thing. what that did is requested data from the same domain. inter-subdomain and subdomain-domain requests are not "same domain", just to make things clear. Since that page was "same-domain", it was possible without a helper.
AJAX does not allow cross-domain requests. as far as i know, there are methods that allow cross-domain requests (such as helper pages)
currently, jsonp is supported by jQuery and you can do it like this:
http://api.jquery.com/jQuery.getJSON/
look for in the page: "Loads the four most recent cat pictures from the Flickr JSONP API."
or see reference:
http://en.wikipedia.org/wiki/JSONP
Theoretically you'll need a proxy iframe with the same domain where the ajax page lies.
postMessage from parent page to iframe page.
And then ajax from iframe.
If you dont have access to the parent page's source code, you can inject your script via a bookmarklet or so. Injection can also include jquery and the postMessage plugin along with your script that creates an iframe.
I'm using this postMessage plugin and it works on latest IE/FF/Chrome/Safari with HTML5. It claims to have URL #ing fallback for older browsers but I haven't tested yet.
http://benalman.com/projects/jquery-postmessage-plugin/
Getting directly the current iframe's URL, in javascript, is not possible due to security restriction.
Is there a way to override this restriction?
Using ActiveX control?
Changing the browser's security options?
Using HTML5?
Using flash?
Using server side scripting?
Getting directly the current iframe's URL, in javascript, is not possible due to security restriction
If you mean cross-domain IFrames, and you have no way of controlling the inlying page, then this is correct.
As far as I know, no, there is no way to get around this.
The only way I can think of - and you don't want to go down that road - is proxying every page inside the iframe through a local server script, rewriting every link and action within each page to go through the proxy, too. But that is hugely difficult, comes with a shitload of things to be aware of, and is not a real option - many modern sites will simply break if proxied that way.
As I understand it if you have no control of the frame you are not supposed to know what is going on in this frame. So, knowing it would be a security bug and should be fixed. Browsers are designed to not allow the page spy on what you are doing in another page.
If you have control over iFrame there are some options for you
There is a discussion here:
How do I get the current location of an iframe?
basically
var iframe = document.getElementById('loader').src
You can actually get the location if iframe is located at the same server. If it is located at a different server the only way to go is to rewrite URLs like some sites do. It is not easy to do though
You can also do HTML5 cross-window communication:
http://ajaxian.com/archives/cross-window-messaging-with-html-5-postmessage
We are using a custom protocol handler to connect to an embedded device across firewalls, NAT etc. The solution is called Nabto.
This works great - a plug-in on the user's computer handles requests to all nabto:// URIs and serves HTML pages with information about the current connections etc.
Now, we would like to access Nabto functionality from a regular web page. This is difficult with browsers enforcing the Same-Origin policy (e.g. our http page cannot communicate with the nabto page).
So far, I am trying to solve this using easyXDM by having a "proxy page" served by the nabto plug-in. This page is then allowed to launch nabto:// requests and can communicate the results back to the http page using easyXDM.
However, same-origin requests fail in Internet Explorer - even when both pages reside in the nabto://self domain. I get this error: image
Is this an error in Internet Explorer? Any idea how to solve it?
Thanks a lot,
Martin
We had huge issues that sound similar to yours when developing the plugin. I must admit that we gave up getting clean Ajax support working through Nabto after spending a lot of time on it. In fact, the final thing that happened was opening a support case with Microsoft about it, the case bounced around and we never heard anything back.
There might be a chance though for a hack: In the meantime we realized that IE allows you to populate images through nabto:// urls on an http / https page. Maybe you can populate an image object through your query and extract the result from there?
On a side note: You are welcome to post in the support forums (forum.nabto.com) about such things. On the other hand, you help spread the word about the product in this way ;-)
Ulrik