I'm generating iframes dynamically for a lot of different random websites, and I tend to get this error in my javascript console (not necessarily with this url):
Unsafe JavaScript attempt to access frame with URL http://localhost:3000/results/ from frame with URL http://www.apple.com/iphone/. Domains, protocols and ports must match.
Why am I getting this error? Is there a way to get rid of it?
So the only two times I interact with iframes in javascript is when I dynamically load in an iframe:
$("#results_div").html('<iframe src='+url+' frameborder="0" class="iframe"><p>Browser does not support iframes.</p></iframe>');
and when I pull the src attribute of an iframe:
var previewed = $("iframe").attr("src");
Which one is causing the error?
Script in your iframe is trying to access parent's script/dom and they are in different domains. Cross domain scripting genrally generates that error.
In your case, apple.com and localhost are different domains and something in those iframe is trying to access its parent window's script or dom element.
Couple of ways to solve this:
Make sure both belong to same domain: http://www.google.com/url?sa=t&source=web&cd=2&ved=0CD0QFjAB&url=https%3A%2F%2Fdeveloper.mozilla.org%2Fen%2FSame_origin_policy_for_JavaScript&ei=VHsaTtqtGcPngQeLvN31Dw&usg=AFQjCNF2yi5TJQGfSywsrfxVvKdsQYzIKg
Limited: Use HTML5's cross domain messaging via postmessage: http://ajaxian.com/archives/cross-window-messaging-with-html-5-postmessage
Limited: Use JOSNP calls: http://www.zackgrossbart.com/hackito/jsonp-sop/
This is due to the fact that your script is trying to acces some code on another domain. This behaviour can be understood by reading Same origin Policy. http://en.wikipedia.org/wiki/Same_origin_policy
There are workarounds and some implementation by which you can resolve this issue.
Some of them are using proxy approach, Fragment identifier approach.
In HTML5 we can use postmessages to get this resolved.
But you have to figure out what may work for you.
You cannot interact with a different domain with javascript or iframes apart from loading the domain with the into the iframe.
Related
I am trying to access a function located on the parent page from an iframe. I get the following error since they're using different sub-domains:
Uncaught SecurityError: Blocked a frame with origin "http://subdomain.domain.com" from accessing a frame with origin "http://subdomain2.domain.com". Protocols, domains, and ports must match.
I am using:
window.parent.myFunction();
to access the function on the parent page.
Is there a workaround for this or will it simply not work because they're different sub-domains?
Blocked a frame with origin "http://subdomain.domain.com" from accessing a frame with origin "http://subdomain2.domain.com"
If you add the line:
document.domain = 'domain.com';
to the scripts in both frames, they will be able to interact directly with each other's objects. See MDN for background.
However cross-frame scripting is strewn with nasty corner cases, where one frame executes something from another frame whilst that frame is busy doing something else, or isn't yet fully loaded. For anything non-trivial, I would avoid direct cross-frame scripting.
The more modern alternative is to keep execution within a single frame, and communicate across frames using postMessage. Support.
This will only works if you have access to the parent domain (e.g. upload files there).
Inside your iframe page, create a second iframe with a source pointing to a page in the main domain.
The second iframe can call a function in the main page by using window.parent.parent.myFunction();
No, this is a security issue and you will not find a way around it.
I have heard that you can use jsonp for getting info from another domain but I have never tried it.
You cannot make the parent do anything though
Now I know there are a lot of resources about same origin policy, but I just want a straight up answer for my specific query as I am really struggling to understand.
I am using Facebook plugins on my website, these create iframes that are only visible in the DOM when I use chromes inspect element etc.
Is there a way that I can access these iFrames properties/attributes at all, or is it a resounding "NO CHANCE!". I am spending far too much time on this and I just need to get a final verdict.
Thanks!
Javascript doesn't see the iframe content. Chrome inspector just loads 2 different websites in the same time, yours and the plugins one, so you can play with both of them.
Just curious, how would you like to change it?
In general, JavaScript cannot access iframe content from outside of the iframe, unless the page domain and the iframe domain share the same protocol and host and port. In your case, this could possibly be done using a proxy server to load the iframe content from your domain.
http://en.wikipedia.org/wiki/Same_origin_policy
After reading this compendium of methods here Ways to circumvent the same-origin policy it's apparent that any workaround requires modification of the target iframe code to get communications across domains.
Unfortunately on this project I'm working on I may only modify the parent page's code, the iframe is provided from another source and is untouchable by us. Are there any methods that don't require modifications to the iframe code?
The only solution then is to fetch the iframe content from your server, either through a proxy or through specific code, and serve it yourself so that the browser only sees one origin.
But be aware that this usually breaks the rules or contract of normal use of the site providing the iframe. If they didn't include CORS headers to allow inclusion and access, there's probably a reason.
No, there cant be such a method, that would kill the security.
When you put an image from an other domain in a canvas, the canvas is tainted and some functions like getDataURL or getImageData are disable.
When you try to use such function a SECURITY_ERROR error happen.
Why is this protection in place? What sort of attack used this method?
Thanks!
edited :
I should ask : How can an image coming from an other domain be used in a attack?
I can't figure out why browser limit used of canvas after beeing tainted.
That is a cross domain blockade, it is simmilar to fact that you cant access elements from an page inside of iframe and such...
EDIT:
From the w3 documentation:
Note that the URL given in the 'src' or 'data' attributes must be on
the same domain as the web page and follows the same domain rule (i.e.
same protocol, port, etc.); cross-domain object insertion is not
supported for security reasons.
But I bumped into this, maybe you could work out something:
http://dev.w3.org/SVG/tools/svgweb/docs/UserManual.html#cross_domain
By the way cross domain in java script could work on newer browsers, but you need to own both domains, and configure the connection so that is considered trusted, see here:
http://www.nczonline.net/blog/2010/05/25/cross-domain-ajax-with-cross-origin-resource-sharing/
I have a web page with some javascript inside that will be embedded as iframe in different websites. I need to adjust the behaviour of my page according to the website in which it's being run. For this purpose, I tried to read top.location.href from my page, but that raised an error:
Unsafe JavaScript attempt to access frame with URL http://website.url
from frame with URL http://mypage.url. Domains, protocols and ports
must match.
Is there some way to go around this?
In the most common case you can indeed retrieve the parent url of the iframe. If the iframe is just one level deep this method will work:
var parentURL = document.referrer
https://developer.mozilla.org/en-US/docs/Web/API/document.referrer
I've used this method when creating iframe widgets. Just remember that if you want the top level window location, but it is not the parent window of your iframe...you won't be able to get it. Also, if your widget navigates within the iframe the referrer will then change.
Yet another excellent write-up by Nicholas Zakas can be found on his blog here:
http://www.nczonline.net/blog/2013/04/16/getting-the-url-of-an-iframes-parent/
This is as you stated the same origin policy and it is in place for security reasons. Without changing the users browser there is no way around it.