Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
Skill Level Intermediate
Communicating across domains is a common problem for web application developers. Major browser vendors consistently implement a security policy called the same-origin policy. This prevents a script from one site from manipulating properties of a document loaded from another site. These different sites are called origins. This important security policy is effective in preventing session hijacking and phishing attacks, and like most effective security policies, it can be frustrating at times, like when you have a legitimate need to have scripts communicate with each other across different origins.
So what exactly is an origin? An origin is made up of three components: the protocol, the host, and the port. If any of these three components are different, the origins are different. For example, if you have one document at this URL and another document at this URL, are they in the same origin? These two URLs are in the same origin. They have the same protocol, the same hostname and they have the same port number, which in this case is the default port number, port number 80, because none is specified.
This URL is also in the same origin. The document itself is in a subdirectory, but that doesn't change the origin. The origin is not dependent on the directories; it's dependent only on the protocol, the hostname, and the port number. This document, on the other hand, is in a different origin. You'll notice that the hostname is different because it says blog. instead of www. Even though that's the third level of the domain, it's still significant. Any difference in the hostname will make a difference in the origin.
This one is also a different origin because the protocol is different. Here it has https instead of http. And this one is also different. Even though the protocol and the hostname are the same, this one specifies a port number that's different than port number 80. So let's take a look at an example so that we can see what happens when you try to access an object across different origins. Here I have two documents that are loaded up at two different URLs that are on two different origins.
First of all, let's take a look at the documents. Especially for those of you who are following along at home without the exercise files, I'm just going to page through this really quickly so that you can see the whole thing. And the same with the other document. That one is crossDomainOneError, and this one here is crossDomainTwoError, and you'll notice that it's a little bit different. Now there is a lot of support stuff in these two documents, but for the most part all they do is one loads up the other in a frame and then it tries to access the title from that other document.
So here it is, loaded up in a browser, and they're on two different domains. The outer document is loaded up from the host one.3sn.net, and these are just a couple of domains that I have that I use. And the inside one is loaded up from host two.3sn.net. And you notice that the error message comes up here that says, "Permission denied to access property 'document'," and the reason for that is right here. Here we are, in document 2, and you'll notice in the init function, it loads up this variable windowOne from parent, which is the window object from the parent window that loaded up the frame.
Remember, this document is inside of a frame. And then it tries to access the document title from that parent document, but it's in a different origin, and so you end up with this error. If instead I load them up from the same origin--and I can do that by coming in right here and just changing this hostname and I'll explain this trickery in a moment here. I'm just going to change it so that it's loading up a document off of the exact same domain and it's exactly the same document.
And when I reload--I'm going to press Reload here--you'll notice that it works, and it's actually able to get that parent title. Now it's important that you understand how I have this set up, and you're going to need to do something like this in order to efficiently play with these examples and learn about the same-origin policy. I'm a big proponent of learning by experimenting and trying things and failing and figuring out why. So in order to do that, what you're going to need is to setup where you have the example files on a server--not on your local machine on your Desktop, but on a server that you're accessing using domain names-- and on that server you have several different domain names pointing at exactly the same file system.
And so what I've done here is I have a cloud server at Rackspace, and you can use any of the cloud server providers or whatever server you have accessible to you. And I've simply used a few domains, and I've set up Apache so that those few domains point at exactly the same file system. So I have all these files up there once, but they're actually accessible from one.3sn.net and two.3sn.net and three.3sn.net. Now in order to do this, you are of course going to need to use your own server and your own domain names. And you really need to have some kind of a setup like this in order to follow along with the examples in this course.
So the HTML5 messaging API provides an effective way to work around the same- origin policy, so that you can communicate with your own scripts on different origins. We'll take a look at how this works in detail in the rest of this course.