How do I get around cross domain issues using the embedded iframe method? Meaning I have Domain A and Domain B and want to embed Domain A on Domain B to bypass the same origin policy? A detailed example would be great!
The method you're describing involves creating a 'helper' HTML file on each domain. When you load Domain A, you also load the helper HTML file on Domain B in an iFrame, which allows you to pass information between the 2.
Check out this post as well about iFrame Proxying
http://www.tomslabs.com/index.php/2012/06/iframes-and-javascript-cross-domain-security/
Be aware of the security implications of doing this as well, perhaps checking in the helper HTML files that the parent iFraming them is in fact your own Domain A/B and not somewhere else.
Related
I am trying to embed or get the content of a https website and tried already some ways:
Iframe - is forbidden:
[Error] Refused to display 'https:// any url ?width=100?data=data' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'.
Get the content with tunnel - CONNECT request. Is not allowed.
Is there any way, how i can achieve this? I have read many old posts, that this is possible, but i think all of them are deprecated. Can i proxy the website somehow?
Thanks for your help!
The browser adheres to the directives stated in headers found on web resources response, for various security reasons (e.g., X-Frame-Options header that prevents loading in an iframe).
Old bypass methods that you might've found for these restrictions, are bound to be prevented eventually as they are considered security holes.
Notice that these are client-side restrictions. I believe that methods that involve a special client or a service that ignores these restricting headers, might be the right path to your problem. It all depends on what you're trying to achieve (Just showing the secured page content? Allowing the user to interact with the page? User can log-in to the secured website? etc.)
For example, a web service that fetches a page and serve it to the requesting client without the restricting headers.
This method isn't bulletproof - You might need to rewrite the resource's URLs in the HTML, deal with cookies, prevent javascript code from detecting if the page is in an iframe, etc.
In my webpage from donain A I show another website from domain B in an iframe. I think website B can choose some fresh colors so I want to edit the background color of the body and change it to blue.
If I try this with javascript by getting the DOM of the iframe, and then editing the body's background color, I get a security error because website B is on another domain.
If open up the developer tools (F12) and I just edit the dom there it works fine.
So I'm really confused: why would a browser allow me to edit the dom by hand, but not by javascript? Obviously any kind of security measures this cross domain policy is supposed to imply is compromised by anybody who can press F12, thus it makes no sense for the browser to block access.
Alternatively, I could just scrape website B with my server, and put the (illegally) retrieved HTML inside my own website (with a nicer color). Again I bypassed the cross domain policy and thus did what the cross domain policy forbids me to do.
As a related question, is there anyway to change the color of an element with javascript inside an iframe without getting a cross domain error?
why would a browser allow me to edit the dom by hand
If is your browser. It trusts you.
but not by javascript?
Your browser doesn't trust the person who wrote the JavaScript on Domain A with the rights to access the data that the person who wrote the page on Domain B gave to you.
What if Domain A was a random site you found linked in your email and Domain B was your online banking?
It is important to remember that there are potentially three people involved:
The person controlling the browser
The person controlling Domain A
The person controlling Domain B
Some of those may be the same person, but they may not and the browser has no way to tell.
Alternatively, I could just scrape website B with my server
In that case, Domain B is trusting Domain A with the data in the first place.
Domain A wouldn't have access to things that your browser has access to (such as your cookies for Domain B) which might cause Domain B to give you different data (like your own banking records).
As a related question, is there anyway to change the color of an element with javascript inside an iframe without getting a cross domain error?
Only with the cooperation of Domain B, in which case you could use postMessage to ask Domain B to change the colour. (Domain B would have to register an event listener so it could hear the request).
The Same Origin Policy prevents malicious Javascript from interacting with other domains.
Otherwise, attackers could write code that silently interacts with your email or bank account.
The dev tools assume that you will not be evil and attack yourself. (this assumption is not always true)
I'm maintaining an application that goes sort of like this:
There is a Page A with a Frame that shows Page B. Now page B is part of a completely different product in a separate domain.
Now, they want that when an option in B is clicked, the WHOLE page is redirected to another page in A. The problem is that the url of A is something like www.client.A.com/Order/Details/123, and when we click in be it should redirect to something like www.client.A.com/Order/Edit/123 but B doesn't know anything about A. It doesn't know which order # is currently selected or anything about A. Page A who has the frame B does know it.
For now my solution has been to just redirect to the AllOrders so something like client.MyCompany/Orders
but since B doesn't know which client is calling it (its a multi-tenant app), I'll add it in the webconfig. (so each client has its own webconfig with a different value).
I dont find this solution optimal but I can't think of anything else! I already tried putting the needed url in page A in a hidden Div (since A does know all the info) and then trying to read the whole DOM of the page from B to find it.... unfortunately I can only get access to Frame B's DOM... (I tried with jquery).
I know frames are evil, but this is how it is written... any ideas?
Thanks!
If the parent page A and the iframe page B are in different domains, you will not be able to access methods or fields via B's parent property, nor will script in A be able to reach into B's content, nor will you be able to share global variables between A and B. This boundary placed between page A and page B is a key part of the browser security model. It's what prevents evil.com from wrapping your online bank web page and stealing your account info just by reading the internal variables of the javascript of the bank's web page.
If you have the luxury of requiring the latest generation of browsers, you can use the postmessage technique mentioned in one of the other answers here. If you need to support older browsers, you may be able to pass small amounts of information using cross-domain client scripting techniques in the browser. One example of this is to use iframes to communicate info between the outer page A and the inner page B. It's not easy and there are many steps involved, but it can be done. I wrote an article on this awhile ago.
You will not be able to monitor clicks in B's iframe from the parent page A. That's a violation of browser security policies at multiple levels. (Click hijacking, for one) You won't be able to see when B's URL changes - A can write to the iframe.src property to change the URL, but once the iframe.src points to a different domain than A's domain, A can no longer read the iframe.src property.
If A and B are in different subdomains of the same root domain, you may have an opportunity to "lower" the domain to a common root. For example, if the outer page A is hosted in subdomain A.foo.bar.com, and B is hosted in subdomain foo.bar.com, then you can lower the domain in page A to foo.bar.com (by assigning window.domain = "foo.bar.com" in A's script). Page A will then behave as a peer of page B and the two can then access each other's data as needed, even though A is technically being served from a different domain than B. I wrote an article on domain lowering, too.
Domain lowering can only peel off innermost subdomains to operate in the context of a root domain. You can't change A.foo.bar.com to abc.com.
There is also a slight risk in lowering domains to a common root domain. When you operate your page in its own subdomain, your html and script are segregated from the other subdomains off the common root domain. If a server in one of the other subdomains is compromised, it doesn't really affect your html page.
If you lower your page's domain to the common root domain, you are exposing your internals to script running on the common root domain and to script from other subdomains that has also lowered its domain to the common root. If a server in one of the other subdomains is compromised, it will have access to your script's internals and therefore it may have compromised your subdomain as well.
in case the page & frame are not on the same domain, you'll have to use postmessage as the same-domain policy prohibits normal javascript-communication between pages/frames of different domains because of security concerns.
postmessage is part of html5 and works in all modern browsers (including IE8). if you need support for older browsers (specifally IE6/7), you could use the jQuery postmessage plugin (which transparently falls back to some nice hash-tag trickery for older browsers).
and as a sidenote: not sure if frames are evil, there are some problems (usability, SEO, ...) related to them, but i did some research and most of these can be tackled i think.
If you want to communicate between frames in javascript you can use 'parent':
If frame A has a variable value, eg:
var orderNo = 2;
For frame B to read it it would refer to
var frameA_orderNo = parent.frames[0].orderNo;
(assuming that frame A is the first frame declared)
So you can set up global variables within each frame that the other frame can read and therefore you can get the order # in old fashioned javascript (never tried it in jquery).
Wow frames - never thought I'd think about them again.
I am trying to load a a page into an iframe. When that page is loaded i wish to edit the contents of the "pre" tag which is inside the loaded document. The loaded doc is from another domain. I am using : resultframe is the iframe
var atag= document.getElementById("resultframe").contentWindow.document.getElementsByTagName('pre');
atag[0].innerHTML="done";
to access the tag.
problem: there seems to be no effect of this statement. I need to know the correct syntax and also that can i access the elements of pages loaded from different domain. I got the syntax from the web and also some variation of it.
Please suggest.
While JavaScript is limited by cross-domain policies that prevent interaction with another domain, there is one potential workaround as long as you can live with certain limitations.
By using something like PHP and it's cURL library you can grab the contents of a page from just about anywhere (even a secure page or one that requires a login, as long as you have credentials). You can then parse the page, edit what you need to, and display it within your own site. It's important to realize, though, that this is simply your own local copy of the page. You won't have the luxury of actually changing the contents of the page itself.
Another possibility, which would require access to all domains you wish to edit, would be to employ a web service that would accept edits in the form of a PUT request. You can achieve a lot more with a web service, but it would have to be available on all target domains that you wish to make changes to.
In the near future, XMLHttpRequest Level 2 might become a reality and will bring Cross-Origin Resource Sharing (CORS) with it. CORS will allow web applications on one domain to make cross domain AJAX requests to another domain. The target domain will have a header giving express permission to allow requests from another. Potentially, this could be used to send edits to another site.
You can't. Browsers have cross-domain policies, for security reasons.
What if I included the facebook page in an iframe, and I can get all your information because you're always connected to it?
I have two domain names that point to my website, nathannifong.com, and uncc.ath.cx.
Javascript on the site occasionally needs to pull down resources with XMLHttpRequest. All URLs of resources in client scripts refer to nathannifong.com, and when a user comes to the site by uncc.ath.cx, the scripts fail because of cross domain secuity policy in JavaScript.
What should I change so that users can come to the site by any domain name, but the XMLHttpRequests still work?
If you are using the Domain Name in the URL's to make a ajax request, remove it hence the domain is automatically mapped to the one the user is using and you will not have the cross domain issues.
xhr is contrained by the same origin policy and will not work cross domain - for that use jsonp as already mentioned.
According to The CodeProject, JSONP would be a way of accomplishing this. I've not used it myself, however, but it might be worth taking a look there.
You could look at window.location to determine the page's domain, and then use that to load the request? That way you'd be sure that the request was going to the right domain. You could also look into JSONP, but only for GET requests.