I need to incorporate in my web application some content from an external dynamic web page on which I have no control.
Then I need to filter some of the content of this page or to hide it for presenting only the relevant part that is interesting for my use.
I need also that the scripts on the external page are still working on the source site of the loaded content without cross-site protection.
Is all that possible? How can I do it? Any code example, please?
I suppose that this can be made with JS on client side .
I work on back side and these themes are quite extraneous to me, please don't blame me.
No, it is not possible.
Browser same-origin policy is designed to prevent malicious websites from doing evil.
Same-origin Policy restricts JavaScript network access to prevent evil.
Same-origin Policy also restricts script API Access to prevent evil.
From the Docs:
JavaScript APIs like iframe.contentWindow, window.parent, window.open, and window.opener allow documents to directly reference each other. When two documents do not have the same origin, these references provide very limited access to Window and Location objects.
To communicate between documents from different origins, use window.postMessage.
— MDN Web Security Reference - Cross-origin script API access
One can not use <iframe> elements as a way to "avoid cross site problems". The Same Origin Policy was created to protect users from evil web pages.
I've read about the cross-domain policy and the restrictions it has in terms of access when we don't have access to both parent and child domains in order to allow access.
However, I was wondering if I have access to parent page and not child page of the iframe is it still impossible to get the iframe to display all links within as href links like http://example.com and not example?
I've seen some scripts before but these are all server side and the links within the iframe are adjusted based on user's country so these scripts don't serve my purpose
All help appreciated
I have a look at these two questions and i don't understand.
Redirect parent window from an iframe action
How to prevent IFRAME from redirecting top-level window
On one hand it appears that you can redirect the parent iframe and on the other you cannot?
When i try it, I have no problem redirecting the parent frame so i'm curious as in why everyone say you cannot redirect parent frame unless you are on the same domain. But I can redirect without having the frame on the same domain.
As stated previously, will redirect the parent iframe. One thing to bear in mind is that both the website, and the site contained in the iframe need to be on the same domain for this to work, or you'll get an access denied exception.
Is it browser related?
Edit
I have two pages and this works but shouldn't :
On domain 1
<html>
<body>
<iframe src="http://domain2.fr"></iframe>
</body>
</html>
On domain 2
<html>
<body>
<script type="text/javascript">
window.top.location.href = "http://google.fr";
</script>
</body>
</html>
The answer to Why it is possible is perfectly simple. window.location is part of the Web API, which is not exactly the same as the JavaScript core. It's part of the DOM interface, hence it's gouverned by W3C, not ECMA. That's why it allows you to manipulate the top-window's properties.
Strictly speaking, JS isn't capable of doing this, because it lacks IO capabilities, which makes the language extremely portable. That's why browser implementations require the DOM API, to query the DOM, and request repaints or interact with the client. The DOM, though, does need IO, because it renders, and reads from the actual UI. Some people in the ECMAScript committee would rather have seen the access to the window.top heavily restricted, if not removed all together, for XSS vulnerability reasons. Sadly W3C agreed to disagree, and implemented the window.top reference anyway.
Who's right or wrong in this case? I don't know, it's easy to redirect a client to a malicious site from within an iFrame, which is unsafe. But it would be frustrating to have an iFrame, and then not having access to the top window, which would mean not being able to interact with the client as easily. But that's not the point here. Bottom line is, you can change some top window properties, and it can be useful. Just think about mashups. They pose a lot of challenges in terms of XSS safety, but open up a lot of new and exciting possibilities for webaps. To plug some of the most dangerous XSS vulnerabilities, take a look at ADSafe, which was created by Douglas Crockford. Google has a similar lib, but I forgot its name ATM...
the Same origin policy doesn't apply here, either. By changing the url in the address bar in your browser window, you're changing the window.top.location.href property, too. If there were same-origin restrictions there, the internet would be dead. You're not sending a request to another location, you're not getting data from a third-party resource and loading it in your page, you're redirecting the browser to another location, which closes and clears the DOM.
My guess is that it is the same reason you can do the following:
Redirect top to Google
I found the rules for this behavior here: http://www.w3.org/TR/html5/browsers.html#valid-browsing-context-name-or-keyword
I couldn't find a "why", but personally I have found it useful to redirect the parent after someone has clicked on something within an iframe. You may want to first perform an async operation and validate something before redirecting the entire page. Since this is already possible using the <a> tag perhaps it was found appropriate in JS as well. Not sure why the <a> tag allows the functionality though.
That being said you can always prevent this behavior by adding sandbox="" attribute, example: http://jsfiddle.net/ppkzS/1/
Whenever you use iframes, frames, or objects, you set up a hierarchy of windows, with these items acting as "window"s in this hierarchy.
You can traverse this hierarchy with properties such as .parent, .frameElement and the like. The property .top is the window at the highest point in the hierarchy and usually corresponds to the outermost frame.
Some actions are prohibited between windows in the hierarchy, others are not. Changing the location of a window is not prohibited.
Ultimately, people who say you cannot do this are incorrect. What you can't do is access the contents of one window from a different window if their domains differ. However, you can modify their location properties.
If you have two frames on the same domain (and also same protocol and port too), then one frame can redirect the other to wherever you want, and also access javascript properties, execute function from the other frame, etc.
Should you redirect one frame from the other to another domain (or protocol, or port), then you would lose the ability to do all that I previously stated due to the Same Origin Policy, but the redirect itself is allowed because, before the redirect, the two frames satisfied said policy.
Here is some useful information: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript
Quoting from that page:
Two pages have the same origin if the protocol, port (if one is
specified), and host are the same for both pages.
Obviously, frames is the same as pages.
I have 2 sub domains
passwordservices.example.com
computers.example.com
All computers are attached to the computers.example.com
A workstation called PC123456 on the domain has a fully qualified name is
PC123456.computers.example.com
The web pages are hosted on passwordservices.
How can I write a javascript that's hosted on PC123456
And access DOM elements on password services.
Basically, JS believes that even a subdomain such as img.yourdomain.com is a different domain from www.yourdomain.com. Because of that, AJAX across pages from those two subdomains will not work. Also if you have an iframe from one to another, you will not be able to refence JS vars or functions back and forth.
A way around this involves setting up an iframe html on one domain and then calling that iframe from the page on the other subdomain. You have to set the document.domain to the same thing on both the parent page and its iframe, in order for them to talk to each other.
document.domain = "yourdomain.com"
Source: tomhoppe.com
You might also want to look into Cross-Origin Resource Sharing
Good Luck!!
Disclaimer: I'm going to do my best to explain what I'm after, but I have pretty limited knowledge about cross-domain policies. I have searched around Stack, but if there's an answer I missed, please let me know.
We implemented the standard Facebook Like/Send button on our site. The Like and Send buttons live inside an iFrame pointing to facebook.com.
When you click on the Send button, HTML is appended as a sibling of the Facebook iFrame (ie. to our DOM).
What I want to know is how FB was able to add HTML to their div on our site without violating cross-domain policies.
Here's my fiddle. To see what's happening, inspect the DOM while clicking Send.
Thanks to #CBroe for pointing me toward the answer:
via Mozilla
window.postMessage is a method for safely enabling cross-origin communication. Normally, scripts on different pages are only allowed to access each other if and only if the pages which executed them are at locations with the same protocol (usually both http), port number (80 being the default for http), and host (modulo document.domain being set by both pages to the same value). window.postMessage provides a controlled mechanism to circumvent this restriction in a way which is secure when properly used.
Because you add send button with javascript, not with iframe. Iframe is producing when your page is loading/just after loaded.
Since this reason script is able to reach your and Iframe's content and DOM elements and edits them. As you know and mentioned, iframe cannot reach it's parent anyway.