I have a JS file that puts an iframe on every site its on.
both the JS and the iframe location comes from the same domain, mine.
Can I somehow communicate from within the iframe to the outside script,
which isn't running on my domain, but is called from it?
I know about JSONP but i'm looking for a better way if possible
It's very simple. The location of the document needs to be served from the same domain as the location of the script. Otherwise, the script will get "Access Denied" error.
If you are supplying a script for other people to use, then you could have them load easyXDM which would allow your script to communicate with the document loaded in the iframe (if it also has the easyXDM library set up).
You would also have to require them to host a simple html file on their domain in case easyXDM cannot use postMessage and has to resort to using the hash/fragment solution.
Demos of this can be viewed here
Related
I want to make some changes to the HTML document inside the iFrame which is coming from another domain, as an example, the document inside the iframe open links to target="_blank" and I want to change that target to another value before it's renders to the client's browser.
I always hit CORS Cross-origin resource sharing, I know this is against security purposes but my application is just a prototype for concept proofing.
I also tried to make it programmatically from the code behind the HTML by storing html content to a variable then pushing the contents after changing to a temporary HTML page, but have the same problem rather than faulty page that require some resources on the external source.
Does anyone know a solution or an out of the box idea that can overcome this issue?
You cannot do it just with a browser, no; as you mentioned, it runs afoul of the Same Origin Policy. (Well, you could with a browser extension, but I'm assuming you're talking about something that would run in a normal environment without additional installation.)
You could do it by involving a server: Have your iframe use a URL on your server, and have the server fulfill requests for that URL by querying the third-party server for it and then relaying the result.
But not without something in-between like that.
I'm reading about the same origin policy. I understand that the js on my page should not have access to methods (and more) defined in a js resource on a different domain. However, I must be misreading this. In my website, I have a script reference to the jquery library at the code.jquery.com domain,
<script src='http://code.jquery.com/jquery-1.8.2.js'></script>
and everything in that library is available to the js scripts on my site.
So, what am I misunderstanding here?
The same-origin-policy says that you are not allowed to use objects etc. declared in another domains i.e. in an iframe.
It does not forbid to load a script from a domain and run the code locally. The variables in the jquery script are not from another domain, you just loaded the source code from there.
Same Origin Policy affects iframes and XHRs, img and canvas, among other things.
Pointing a script src to a different host, protocol or port is not in violation with this. This is useful, as we can use a CDN to serve the files and use JSONP for data transfer (before CORS can be used everywhere - thanks < IE8).
I want to serve my JavaScript scripts from a CDN like cloudflare.
Now my scripts communicate with my app server via ajax. Wouldn't the same-origin policy restrictions come into play when I load these scripts from a CDN?
Let's say my app is on the domain:
http://app.com
And I load my scripts from
http://cdn.com/xyz/all.js
Now, since my scripts are loaded from a different domain than the domain my app is running from, I guess the same origin policy would prevent me from doing ajax communication with my app.
Am I getting something wrong?
No, it will work. That's why JSONP works. The "origin" of the script is the page it is executed in, not where it comes from.
As you asked for it, here's a reference (I couldn't find any better, but Crockford is well known)
The src attribute, surprisingly, is not constrained by the Same Origin Policy. This means that a script element can be created which can go to any server, fetch a script, and execute it. If the script causes the delivery of JSON-encoded data, then this is a very useful thing. Unfortunately, there is no way to constrain the script or to inspect it before it executes. It runs with the same authority as scripts from the page. So the script can access and use its cookies. It can access the originating server using the user's authorization. It can inspect the DOM and the JavaScript global object, and send any information it finds anywhere in the world. The Script Tag Hack is not secure and should be avoided.
http://javascript.crockford.com/script.html
Not really a reference: If this wouldn't work, nobody could include jQuery from Google's CDN and then use it's $.ajax method.
we have a site with Iframes pointing to dynamic Urls (by user input).
In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Is there any solution for this?
Any other suggestions?
Thanks,
Tal
we have a site with Iframes pointing to dynamic Urls (by user input). In case of a 404/500 or any other error, we want to replace the Iframe source with a different user friendly other URL.
So it sounds like you are making a sort of "browser in a web page."
For this we can use with the onerror event to identify when the dynamic websites have problems. (then, in case of problem replace the iframe url)
Yes, except not many things have onerror events. I assume you are aware of this from your comments on other answers. If I understand you right, you're talking about using a dummy script element to load the URL first (as a script, even though it's not really a script), and determine whether the URL is valid using the using onload/onerror handlers for the script element (onerror will not fire on a script error, only a network error).
This works also for cross domain urls, however there might be a case where the dynamic url might be malicious and such security issue rises where the malicious code will execute in the same frame ,same domain of our website.
Is this assumption correct?
Your assumption is correct. If the URL actually does contain a script, it will execute in the user's browser in the same domain as your site.
Is there any solution for this?
A simple workaround might be to do something like what jsfiddle.net does... have a separate subdomain act as a "firewall" between the third-party content and your real domain.
Any other suggestions?
The script preload hack is really just that, a hack. It misappropriates the script tag and makes needless requests. I would probably look into using XHR to fire off a HEAD request instead, or doing some light server-side proxying.
Yes, if you use a <script> tag to embed a remote JS file, you have a security problem as the code is going to be executed in the context of your page.
The only workaround idea that comes to mind is making a server-side request to the resource and parse the response headers. This however may behave differently from a client-side request, as the call will be coming from the server, so it'll have a different IP, different cookies, etc.
If the user can only specify the frame’s URL, then any scripting in the frame’s document would be run in the context of the frame’s document and not in the context of the parent document the frame is embedded.
The question whether a script running inside the frame can access the parent’s document (i. e. your document) depends on the origin of both documents: only if they are equal both document’s are said to be same origin. And only in that case one document can access the other document.
I want to load a whole site into a div. When I use
$(document).ready(function(){
$('#result').load('http://www.yahoo.com');
});
It's not working.
It will be a cross domain call to do using javascript. You can use iframe to load.
Check this link for possible solutions.
This is a cross-domain issue.
You can create a proxy on your server to fetch the data and you'll load it from your own domain.
What do you mean "a whole site", if you mean a given page, then it'll probably require all manner of header included files, which are not suitable to go in to the body of your page.
You would need to use an IFRAME, just create the IFRAME element and set the source to the URL you want.
Although I'm not sure about your use case of loading "whole" site into div - you are limited by "same domain" security policy, in order to make cross-domain AJAX calls you need to employ JSONP call http://api.jquery.com/jQuery.getJSON/
You can't do that unless the content you're loading comes from the same domain as the site you're loading it into, due to JavaScript's Same Origin Policy.
Your alternatives:
load the content into an iframe
pull the content server-side via an HTTP get, and the write it out to your page
Beware of licensing issues with the second option if you don't have permission to use the content, though!