Bug 972226
| Summary: | [RFE] webadmin: ui-plugins: allow messaging between engine-originated-HTML-documents by default (i.e. without custom configuration per engine deployment) | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Einav Cohen <ecohen> |
| Component: | RFEs | Assignee: | Vojtech Szocs <vszocs> |
| Status: | CLOSED DEFERRED | QA Contact: | bugs <bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | --- | CC: | acathrow, bugs, gshereme, mgoldboi, vszocs, ykaul |
| Target Milestone: | --- | Keywords: | FutureFeature, Improvement, Reopened |
| Target Release: | --- | Flags: | ylavi:
ovirt-future?
ylavi: planning_ack? ylavi: devel_ack? ylavi: testing_ack? |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-01 14:46:19 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | UX | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
still relevant? 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 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. +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 @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. We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly. ok, closing. Please reopen if still relevant/you want to work on it. ok, closing. Please reopen if still relevant/you want to work on it. |
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.