Using iFrame for Cross-domain Communication in Enterprise Networks

In this blog, I will discuss the role of inline frames (iFrames) in enabling cross-domain communication between enterprise networks/apps based on our project experience with a leading ISV client in retail/consumer space.

Most IT users are aware of the role of iFrame tag which is commonly encountered during code development. If you want to know more, here is a useful link for a detailed understanding of iFrame theory. iFrames happen to be extremely popular in the enterprise environment because they can be trusted to deliver scalability, agility and future-proof designs.

iFrame helps load webpages very effectively and effortlessly and work to bridge the connections between domains and sub-domains.

For example, if a website named www.domain1.com consists of an iFrame which can lead to any other webpage from an identical domain, then the parameter on iFrame can be accepted to perform any client side action with no trouble.

The main issue that arises in iFrame is cross-domain support which is commonly needed in distributed networks, multi-site architecture and search/reuse activities. Problems arise when iFrame has to communicate via JavaScript in cross domain. Here, based on our project experience at eInfochips, we will demonstrate how easily you can execute/modify your code with better assurance, speed and far less risk.

Challenges in Cross-domain Support

Think of a website domain1.com consisting of an iFrame through which you access another website domain2.com. If you want to perform any action for domain1.com from domain2.com, previously, across old browsers you used to communicate via >window.parent.doaction();

Here, you can call the main domain, (domain1.com) and its parent JS from another domain, (domain2.com) which is childm but due to security reasons, cross iFrame communications have been disabled many years ago.

Nowadays, if you try to call JavaScript function and both applications are on a different domain, the following exceptions may be provided below:

“Permission denied to access property”

“Child document does not have the right to access parent document.”

Solution

There are many ways to achieve a solution but we will focus on current HTML5 (It’s the savior of our entire problem) which is supported by all latest browsers.
HTML 5 postMessage method allow cross-origin communication which is supported by all modern browsers allowing communication between different domains.

Syntax

otherWindow.postMessage(message, targetOrigin, [transfer]);

The window.postMessage method safely enables cross-origin communication to resolve security concerns.

Here, one window will be “the sender” and another will be “the receiver”. Sender can pass parameter/ objects as per the requirement of the receiver.

Concluding Comments

The method described above allows developers working on sophisticated enterprise applications to enable communication support across two or more cross domains (two different windows) in a safe, secure way. This works for all modern browsers. You may also establish two-way communication via source property.

Drop us a line at marketing@einfochips.com for more information on how we can help you support cross-domain communication between various apps.

Some of the potential applications of cross-domain communication using iFrames can be in the field of unified automation in testing. eInfochips has recently published a white paper on our framework, EzTest, which supports unification across web, mobile, PC and desktop devices.