HTML and CSS Reference
Enabling more secure integration with cross-document messaging
In many situations, people like to use widgets from other websites
inside their own pages. Common scenarios where this happens are
Facebook's Like buttons, external commenting systems such as Dis-
qus, and Google Ads. There are two basic approaches for this:
The <iframe> —An embedded window inside your page into which
another web page is loaded. The page inside the <iframe> is completely
separate from the page containing the <iframe> , and standard browser
security prevents them from communicating with each other.
is allowed to create elements and fetch content from the server from
which it came. The script is completely integrated in the host page
and has access to all the information the host page does.
The problem is that there are two extremes. With the
<iframe> , you can guarantee that the widget doesn't have
access to any private data about your users that you hap-
doesn't have access to anything in the host page, includ-
ing any information that might be useful for the script.
script has access to everything in the page, including any
cookies that may be set and any forms the user is filling
in. What's needed is a solution that maintains the privacy
and security allowed by <iframe> s but allows a controlled
flow of infor-mation between the two domains. This is
what cross-document messaging provides.
Faking multiple domains
Experimenting with multiple domains requires that you have multiple domains
available. If you don't happen to be one of those people who collect domain
names, you can fake it on your local machine by editing your hosts file. On Win-
dows, this file is usually located at C:\Windows\System32\Drivers \etc\hosts
(note that the filename doesn't have an extension) and on Linux and Unix systems
at /etc/hosts. The file format is an IP address followed by a number of aliases: