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]
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.
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.
Yes, this BZ is still relevant.
The goal is to reduce configuration  through a sensible default value, which makes things easier for individual plugins.
 http://www.ovirt.org/Features/UIPlugins#Cross-window_messaging_2 - add sensible default value for allowedMessageOrigins
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
This is still relevant I think.
(In reply to Martin Sivák from comment #4)
> This is still relevant I think.
For typical UI plugins utilizing Engine infra  to serve plugin's static files (HTML/JS/CSS/etc.) this RFE is still relevant as it simply means "messages originating from Engine-served pages are trusted by default".
@Vojtech, still relevant?
Yes, this should be relevant, even though I don't know how many UI plugins actually use cross-window messaging.
Code change should be trivial, i.e. make plugin's allowedMessageOrigins contain Engine base URL by default.