Bug 972226 - [RFE] webadmin: ui-plugins: allow messaging between engine-originated-HTML-documents by default (i.e. without custom configuration per engine deployment)
[RFE] webadmin: ui-plugins: allow messaging between engine-originated-HTML-do...
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
---
Unspecified Unspecified
unspecified Severity low (vote)
: ---
: ---
Assigned To: vszocs
bugs@ovirt.org
: FutureFeature, Improvement, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 16:59 EDT by Einav Cohen
Modified: 2017-10-25 05:48 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-16 11:39:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: UX
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑future?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Einav Cohen 2013-06-07 16:59:39 EDT
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.
Comment 1 Itamar Heim 2013-12-01 03:59:58 EST
still relevant?
Comment 2 vszocs 2013-12-09 09:06:12 EST
Yes, this BZ is still relevant.

The goal is to reduce configuration [1] through a sensible default value, which makes things easier for individual plugins.

[1] http://www.ovirt.org/Features/UIPlugins#Cross-window_messaging_2 - add sensible default value for allowedMessageOrigins
Comment 3 Itamar Heim 2014-06-16 11:39:23 EDT
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
Comment 4 Martin Sivák 2015-01-28 11:54:53 EST
This is still relevant I think.
Comment 5 vszocs 2015-02-02 12:20:06 EST
(In reply to Martin Sivák from comment #4)
> This is still relevant I think.

+1

For typical UI plugins utilizing Engine infra [1] 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".

[1] /ovirt-engine/webadmin/plugin/<pluginName>/path/to/file

Note You need to log in before you can comment on or make changes to this bug.