Background:
Today, the web-admin ui plugins infrastructure allows utilization of the HTML5 postMessage API, which allows communication between several ui-plugins-related documents [e.g. an iframe which hosts an external ui-plugin-triggered content and its parent web-admin document (which can propagate messages to the ui-plugin's host pages, for example)].
Once an HTML5 message is posted from a certain document to the web-admin document, the ui plugins infrastructure is checking each plug-in's 'allowedMessageOrigins' array, and propagates the message only to the plug-ins that have the message's origin defined within their 'allowedMessageOrigins' array.
[once propagated, each plug-in handles the message via its own "MessageReceived" event-callback/handler]

Problem:
plugins can use resources that are external to the engine, as well as internal.
("resource" for example: url to be loaded when opening a custom dialog/custom-main-tab/custom-sub-tab/etc.).
if an HTML document [that is hosting such a (internal) resource] wants to post a message to the web-admin document (in order to interact with the ui-plugin host page), it can do that only if the ui-plugin has configured within its options the 'allowedMessageOrigin' array, which should contain explicitly the engine's origin details ("protocol://host:port").
Which means that for each deployment of the engine, the 'allowedMessageOrigin' for the relevant plug-in(s) should be explicitly configured / manually changed to contain the engine deployment's specific origin details.
This interferes with the ui-plugins' "plug-and-play" nature that we would like them to have.

Solution:
need to allow ui-plugin-related HTML documents that are hosting content from the engine (internal) origin to communicate by messages, without having to manually configure the plug-in's 'allowedMessageOrigin' on each deployment/setup with its own origin details.
one way to do that is to change the ui-plugins infrastructure to always accept messages sent by documents with the engine (internal) origin, regardless of the content of the plug-in's 'allowedMessageOrigin'.
another way to do that is to supply a way of retrieving the engine origin details [e.g. api.getEngineOrigin()] and to be able to add this value to the ui-plugin's 'allowedMessageOrigin' array.