|
June 1, 2008
 How to (sometimes) get around cross browser security issues when using JavaScript.
Every now and then I'll post something related to programming; usually after I find it hard to locate a solution to a problem I'm trying to solve. This post is the result of such an issue.
If this post is way over your head when it comes to scripting and web pages, you can get my free course Introduction to Web Site Creation to learn about making web sites, and Interactive Web Scripting which introduces JavaScript, PHP, Forms, etc.
When using JavaScript to access variables or objects in a child browser or in another frame, the domain of both frames has to be the same or you'll get a permission denied error. If both of your pages are on the same site, then this is not an issue. However, if you have two sites that need to share information, then it quickly becomes a frustrating problem.
A Few Definitions
A Frames based page is a web page made up of sections (frames) that are actually separate individual pages. A good example is a photo gallery with thumbnail images in a frame and a big image in another frame. When you click on a thumbnail image, it is displayed full size in the larger frame.
An iFrame is another page embedded in a hole in the parent page: think banner ad.
A domain is the name of the site you type in your browser, for example pqInternet.com is a domain name. It's also a top level domain because it does not have a prefix (such as www). When you type in a domain name into your browser, your computer makes a request to convert the domain name in an IP address which is a number based address that all things connected to the Internet use. By adding the prefix to the domain name, such as www.pqInternet.com, we create a sub-domain. Different sub-domains can point to different sections of the same web site, or entirely different servers.
There are obvious reasons why browser security blocks access between browser iterations that don't belong to the same domain. Imagine an ad network placing an ad in an iFrame, or another type of widget that exists in an iFrame on your page being able to access anything in the parent page. An unscrupulous programmer could do a lot of nasty things if browser security didn't prevent this.
While in general this cross browser scripting security is a good thing, it can get in your way when you have multiple sites that you need to use together in either a frames based page or a parent / iFrame scenario.
I spent a few days beating my head against the wall trying to make just such a situation work. I found a little help here and there, but nothing all in one place that really told how to make it work.
My problem was a parent page from one site driving a child page in an iFrame from another site. Both are my sites. Both have different domains.
Parent - Child - Grandchild Limited Solution
One solution I found suggested having the child contain another iFrame that was in the same domain as the parent page. The child would navigate its child iFrame and append information to the URL after a hash mark. The hash mark (#) is usually used in a link that moves you to a particular location on the page, such as the back to the top links that are common on long pages. The advantage here is that the parent browser will not reload the page if the only thing that changes is the part of the URL after the hash mark. You can setup a timer in JavaScript in the parent page that will detect this and use the information that has been passed back from the child's iFrame. Personally, while this may work, it made my head hurt! Plus, this is really only one-way communication, not two-way.
Internet Explorer 6 Cookie Security
My second attempt was to move all the JavaScript to the child and give up some of the features that I wanted. But after reworking the code, I found my session variables of the child no longer work. Session variables are server side variables that remain between page reloads. They're actually kept in a cookie. I found that this was a security feature added to IE 6 and beyond. You can get around it by added a header value to both the parent and child pages:
In ASP it looks like this: response.AddHeader "P3P", "CP=CAO PSA OUR"
In PHP in looks something like this: header('P3P: CP=CAO PSA OUR");
Put this in both pages and the session variables in the child will start to function again.
But I still wasn't happy. I really needed to have it work like I wanted, with the ability to cross communicate between the parent and child.
Parent - Child Can Talk Solution
So, it finally dawned on me that I control both servers and both domain. So why not add a sub-domain to the 2nd site that was in the 1st site's domain.
For example (and this is only an example):
I want to have a page at www.pqInternet.com contain an iFrame from www.PhaseQuest.com: this would fail; I could load a page from www.PhaesQuest.com in the iFrame, but any attempts at accessing the parent or child via JavaScript will fail with the very irritating error: permission denied.
Step 1 of the solution:
In the DNS Zone of the parent domain (in this case pqInternet.com), create an "A" record pointing to a new sub-domain called marketing.pqInternet.com that points to the PhaseQuest.com server.
What does this do? It let's me load the child page in the iFrame using the same top level domain (pqInternet.com) instead of PhaseQuest.com. Pretty slick huh? Yes, but still no cigar. I still got permission denied. Why?
Step 2 of the solution:
The domains much match exactly, not just top level, but the sub-domain too. So how to get around this? Simple, there's a JavaScript command that you can issue on both pages to set the domain back to the top level domain and not the sub-domain:
document.domain = "pqInternet.com";
Put this at the top of the JavaScript on both the parent and the child pages and BAM!, no more permission denied errors. You can access the parent from the child and the child from the parent.
Again, if this post is way over your head when it comes to scripting and web pages, you can get my free course Introduction to Web Site Creation to learn about making web sites, and Interactive Web Scripting which introduces JavaScript, PHP, Forms, etc.
Until Next Time,
Fred
About the Author
Fred Black is an experienced programmer, web site developer, online business operator, systems integrator, father, husband, musician, and songwriter. Visit his Internet Business Blog at: http://www.pqInternet.com.
|
Posted by Fred on June 1, 2008 | Printer-Friendly
TrackBack: http://www.pqInternet.com/Blog/mt-tb.cgi/141
Assigned Categories:
Web Site Design, HTML, CSS
Related Entries:
|
You may reprint or distribute this article as long as you leave the content and the About the Author resource box at the end intact. |
|
|
|
Post A Comment
|
|
Insert your name and e-mail to receive a short notice each time I make a new post.
NOTE: You will receive a confirmation email. You must click the link in the email to subscribe. Please check your spam folder(s) if you don't receive the email.
| |
|
|
|
|
|
|
|
|
|
|
|
|
| | 
