Cross-Domain
On a web page, when the parent window contains a iFrame
son who is pointing to another domain, there is absolutely no way to access the content of this iFrame
son. In turn, the iFrame
child cannot access any content from the parent window. By content, I mean by using something similar to the document.getElementId('frameid').forms[0]
to obtain a reference to an element, such as a form. There is only one exception to this. If two different domains differ only in their sub-domain. You can use Javascript to set the frame domains for the main domain and then the frames will be able to access each one’s content.
If the frames are in the same domain and then the frames can access each other. To do this, you should get a reference to the element iFrame
usually through the medium of getElementId('frameid')
. Then, there are two ways to access the window object by the iFrame
. The way before the IE8
and the normal way.
function getIframeWindow(iframeElement){
return iframeElement.contentWindow || iframeElement.contentDocument.parentWindow;
}
contentWindow
is what was provided by the browsers before the IE8
. contentDocument.parentWindow
is what exists in modern browsers. You can then use this reference to manipulate the DOM
of iFrame
as you would in the main window.
Some Sources on this:
Communication between frames in different areas
So the only useful thing that really can happen between 2 frames in different domains is communication, one frame sending a message to another frame. There are many ways to do this, but the only certainty is that both domains have to be aware of the communication contract. Otherwise, a frame would send a message to another frame and be ignored. Or a frame would be listening to a message would never be sent.
Communication between domains with different Rvers
When making a request HTTP
in a web page
from one domain to another server in another domain, the rules are still the same: both domains have to be aware of the communication contract. If both domains do not agree to send and accept a message format, nothing can happen. For example: it is not possible to make a request
for http://www.google.com (home page)
with any of the following techniques and use the information that is received because the site www.google.com
is not programmed to know about any specific customer making the order.
Form Posting
The most basic way to send a request to a server from a web site is through a form post
. It is possible with Javascript to programmatically add a iFrame
to the parent window. In that iFrame
, you can add a form that points to another domain. In this form, you can add a series of hidden inputs
that represent the information you want sent to the domain. You can then submit the form that will make a request POST
for that domain.
There is a small problem with this. When the iFrame
receive the response from the other domain, website restrictions will deny other access and you will no longer be able to access the frame to get any information that was sent back. If you simply need to send information, this technique solves.
JavaScript (JSONP)
JSONP
is limited to the extent that it can only make requests GET
, no messages. There is no way for a browser to make a POST
for a script tag. Also, script files on another domain cannot set cookies for that domain.
Ajax
Ajax
allows you to do request
asynchronous for the browser. But this technique is the most demanding for cross-Omain communication. By default, you cannot make an Ajax request for a domain other than the window that is made. In order to do this, you must use a technique called CORS
. This is an official standard that is becoming more consistent across all browsers.
Once again, the same principle applies here. Both the client and the server must know each other, so that the communication channel is established. Ajax CORS
has an advantage over JSONP
, in which he can make requests POST
and the JSONP
nay.
Examples of Cross Domain
- You have to integrate with a third-party service (such as a forum) that has a resident REST API from a different origin.
- Their
server-side services
are hosted in different (sub) domains.
- Your logic
client-side
is served from a different origin than its endpoints
server side.
Have you read what it says on the "cross-Domain" tag, right here in stackoverflow? http://answall.com/questions/tagged/cross-domain
– Fernando Mondo
I just read, let me get this straight, I have my page at this address "http://www.teste.com/enviar.html" and I request a page "http://www.applicao.com.br/requisitado.html", which is cross-Omain?
– Duds
basically, yes
– Caio Felipe Pereira