[ https://issues.apache.org/jira/browse/CB-4897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14148518#comment-14148518 ]
Oran Dennison commented on CB-4897: ----------------------------------- Here's an elaborate workaround using polling. http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser > Support window.postMessage for two way communication between local and remote > content > ------------------------------------------------------------------------------------- > > Key: CB-4897 > URL: https://issues.apache.org/jira/browse/CB-4897 > Project: Apache Cordova > Issue Type: New Feature > Components: Plugin InAppBrowser > Affects Versions: 3.0.0 > Reporter: Lachlan Hunt > > For developing a hybrid web app that will use the device APIs provided by > Cordova plugins in combination with a remotely hosted web application, it is > necessary to be able to communicate between the local and remotely hosted > components. > The InAppBrowser plugin currently only provides limited support for mostly > one-way communication using executeScript to inject a new script into the > remote document. But this is limited because it only allows a single return > value, and doesn't directly allow for ongoing communication. > It would be very useful if window.postMessage were supported by the plugin. > When a message is received by the remote page (via the window.onmessage > handler), the evt.source property can provide a WindowProxy or MessagePort to > be used for subsequent communication from the remote page to the local page. > Other solutions I have considered: > * Using iframe instead of InAppBrowser, absolutely positioned and covering > the full height and width of the screen. > This works, because the Window objects are accessible to both, and posting a > message to iframe.contentWinow from the local content provides a reference to > evt.source (The local Window object). This isn't ideal because it prevents > using InAppBrowser's executeScript feature to first inject a script to enable > the two-way communication features. Ideally, I don't want the server to > include it because I don't want the web app to enable the feature when the > remote page is loaded outside of the native app. > * Creating a new MessageChannel() object and returning one of the ports via > the executeScript return value. > This doesn't work because the MessageChannel() constructor is not yet > supported by WebKit on the devices. > * Loading a remote script directly into the local content, and having that > script populate the DOM with content as needed. This isn't ideal because the > base URL of the document is not a URL to the remote host, so relative paths > don't work, and setting <base href> causes other problems. > * Communication via SharedWorker > This method is the best I've found so far, but is quite complex to setup and > operate securely. > Setup for local page: > * Embed <iframe src="http://remote.example.com/bridge.html"></iframe> > * Generate a secure shared secret key using window.crypto DOM API. (Don't use > Math.random() because it could potentially allow attackers to guess the > shared secret.) > * use iframe.contentWindow.postMessage() to send messages to bridge.html. > * Send initialisation message with the shared secret key to the bridge. > * var win = window.open("http://remote.example.com/", ...) > * When loaded, use win.executeScript(...) to inject the same bridge.html > iframe and the shared secret key into the remote page > Setup for remote page (from executeScript call): > * Embed <iframe src="http://remote.example.com/bridge.html"></iframe> > * postMessage() initialisation to the bridge with the shared secret key > Bridge.html > * Creates a new SharedWorker("bridge.js") > * Messages received by the SharedWorker are broadcast out to all other > listeners that have initialised with the same shared secret key. > Because bridge.html may potentially be embedded into any site and access the > same SharedWorker, the shared secret key lets the worker know which pages are > authorised to post messages, and reject messages received from other sources. > The complexity of that solution would be solved by having native support for > window.postMessage() in the InAppBrowser plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)