views:

373

answers:

3

I'm implementing a "widget" that will be included on article/story pages of a 3rd-party website. This widget lives in an <iframe> hosted on our domain. It needs to gather text from the articles of its parent page (the 3rd-party website), which it then uses to make a variety of API calls to services that return related content, which is then displayed in our <iframe> widget.

I can't access the DOM of the parent page due to cross-domain security restrictions, and therein lies the problem. I can place just about any code that I need to on the parent page (e.g., some JavaScript that parses out the content that I need), and the <iframe> is also totally under my control, but I'm not sure how to get the content from the host page into my <iframe> since they're hosted on different domains. Security is very important and I'd like to find a method that doesn't compromise that in any way.

My initial thought was to pass the page content from the parent page into my <iframe src=""> attribute using a query parameter:

<iframe src="http://www.mydomain.com/widget.html?page_content=This is some page content."></iframe>

I could use a <script> on the parent page to gather the text, then document.write an <iframe> that uses the string holding my text to create a dynamic "page_content" query parameter. The page_content parameter would then be available to my <iframe> page in document.href.

However, I need to gather 8 KB of text from the parent page, and my understanding is that GET requests have a 1 KB limit - is this true? If not, or if I can configure that limit on my server, problem likely solved.

If that is going to be a limitation, how else could I get creative and pass this text into my widget? This needs be a very scalable solution, as the parent website gets tens of millions of page views monthly. I also don't want to impact the performance of the parent page in a significant way.

I have jQuery available in my widget, but can't rely on anything but plain JavaScript in the parent page.

A: 

If you're worried about having too much data for a GET request, use a POST request instead. You could try something like the answer to this question: "How do you post to an Iframe?". Then you could put the data in a hidden textarea and submit the form using JavaScript on the parent page.

wdebeaum
Thanks for your reply, wdebeaum - that's a good suggestion, but wouldn't that involve a trip to the server to then make that POST data accessible to JavaScript within the <iframe> widget? I don't think there's a way for the widget to have access to the POST data otherwise; performance is crucial here so I'd like to avoid extra server trips if possible. The beauty of a GET request in this situation is that it's used more as a means to get easy access to some text (as a query parameter) from a different domain.
Bungle
I don't understand how a POST request would imply an extra trip to the server relative to a GET request... they're both going to the server in order to get the contents of the iframe. Then the server can put the query parameter (whether GET or POST) in its reply in a way that's accessible to the JavaScript in the iframe.If you're saying that setting the src attribute of the iframe should somehow propagate to the document.href property without actually requesting the page from the server, I'm not sure that's true.
wdebeaum
A: 

Actually, you could use the name attribute for this, it has room for quite a lot of data.

On the hosting page, you first create the iframe, sets its .name property to contain the needed data, then set the .src property to load the contained site. This would now have access to its own name, and hence the data.

It is possible that the hosting site would need to set the iframes .src to a local page first, which would capture the parent documents data, put in its .name property and redirect to the inteded site.

Sean Kinsey
A: 

If you have control over both domains, you can try a cross-domain scripting library like EasyXDM, which wraps cross-browser quirks (including the name property that Sean mentions above) and provides an easy-to-use API for communicating in client script between different domains using the best available mechanism for that browser (e.g. postMessage if available, other mechanisms if not).

Caveat: you need to have control over both domains in order to make it work (where "control" means you can place static files on both of them). But you don't need any server-side code changes.

Another Caveat: there are security implications here-- make sure you trust the other domain's script!

Justin Grant