Debugging remote iframed sites

NOTE: This article is focused on users of Windows. The principles, however, should be the same for other operating systems.

The software product which I work on allows for it to be iframed. Furthermore, our product dispatches a series of JavaScript events that the web page which iframes it can act on.

As an example, you can have a catalog with a shopping basket. The pages of the catalog can then contain “links” which add an item to the basket. Now instead of the item being added to the basket of the catalog, the web page which iframes the catalog can instead listen for this event and tell our system to stop since it will take over and add the item to a custom basket that is implemented on the page.

Reported

Now obviously, we have a development environment that allows us to test production scenarios locally. But we had a client report a bug that was not reproducible in our local environment yet the customer insisted he was continuing to experience it.

The catalog was being hosted on an URL of the form:
http://catalogs.abcompany.com/week23.htm

Their web page which iframed this catalog was hosted on an URL of the form:
http://abcompany.com/weeks.htm

The problem with debugging this arose since I did not have access to either of these locations. And because a cloned setup locally did not produce the problem, I had to test if that specific catalog, when iframed, would cause the problem.

Problem

We want to run weeks.htm locally and have it iframe week23.htm which runs remotely. Furthermore, we do not want to run into cross-site security violations.

Given then natural setup this can not be done! If you run weeks.htm locally and iframe week23.htm you will run into cross-site scripting violations before you even get started.

Scenario

1. week23.htm is hosted online.
2. We do not have access to said server (we can’t just upload new versions of weeks.htm to test).
3. We want to iframe week23.htm within weeks.htm, and communicate between them without cross-site scripting restrictions kicking in.
4. weeks.htm will be hosted locally

Solution

I will assume that we are trying to do this on our workstation and thus already have Internet Information Server (IIS) up and running.

Now do the following

1. Setup an IIS website and point it to the directory that contains weeks.htm
2. Bind abcompany.com to said website
3. Add an entry to the “hosts” file (127.0.0.1 abcompany.com)
4. Go to http://abcompany.com/weeks.htm

weeks.htm & weeks23.htm should both include this line

<script type="text/javascript">document.domain = 'abcompany.com';</script>

note: for further information about howto communicate between iframes on different subdomains read this post on the subject

Because we have setup abcompany.com to point to our local machine we are now able to communicate between the two pages without getting cross-site scripting violations even though week23.htm is running remotely.

This unique setup allows pages running locally to communicate with online pages without having any policies preventing this. It is now easy to edit weeks.htm and start debugging.

iPad

In my specific scenario, I needed to test weeks.htm from an iPad. To make this possible I used Fiddler as a proxy which meant I could also access abcompany.com/weeks.htm from my iPad and have it point to the version on my local machine still without cross-site scripting violations.