Bug 1638217

I duplicated. It only happens on Firefox -- chrome is fine.

In admin portal, it's a regular request (cause = 'subdocument' in network tab) for the .vv file. In vm portal, it's an xhr (cause = 'xhr') request. Firefox must not handle that the same.

which Firefox is that exactly?

This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

sync2jira

sync2jira

I looked into this a bit awhile ago, here are my thoughts on doing the console.vv on server side:

  - The console.vv isn't just passed along from the API, it goes through an adjustment.
    The function is in [0].

  - Whatever is done in that function needs to be duplicated on the server code, or it needs
    to be dropped.

  - I don't know why the console.vv is adjusted like this, except maybe to adopt some
    configurations that are stored on web-ui itself.

  - Webadmin will also generate a console.vv file, but the GWT code does stuff and then routes
    the browser along to "/ovirt-engine/services/attachment/console.vv" which is [1].  Looks
    like that servlet just takes POST data and returns it as the response.  The bit of GWT code
    that actually calls it is [2].


Given all of that info, there are a few things that we could do:

  - Reimplement the GetAttachmentServlet in ovirt-web-ui modeled after the branding jsp [3]

  - Maybe reuse the one in webadmin.  It'll probably work as long as the SSO tokens get
    passed along, the URL is formed correctly and web-ui is running in the engine.  Just
    need to get the POST request fired in the right way.  GWT code inserts a form, submits
    it and targets the response to open in an iframe (if I saw things happen correctly).

  - If we want it to work when web-ui is running in dev mode (like how the container does
    it), something will probably have to be done in the webpack dev server proxy configs
    to enable access to something other than the rest endpoints.  Maybe it can be configured
    with another proxy for the GetAttachementServlet when running in dev mode.
    Prod/installed mode would use the jsp or engine's attachment servlet.


[0] - https://github.com/oVirt/ovirt-web-ui/blob/master/src/sagas/console/vvFileUtils.js

[1] - https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/services/src/main/java/org/ovirt/engine/core/services/GetAttachmentServlet.java

[2] - https://github.com/oVirt/ovirt-engine/blob/2b34f2d3b8fa2aea63883e59418148598c4eb05f/frontend/webadmin/modules/uicommonweb/src/main/java/org/ovirt/engine/ui/uicommonweb/models/vms/ConsoleModel.java#L205-L224

[3] - https://github.com/oVirt/ovirt-web-ui/blob/master/packaging/ovirt-web-ui.war/WEB-INF/branding.jsp

Fix: https://github.com/oVirt/ovirt-web-ui/pull/1243

Steps:
1. Open Firefox settings and set virt-viewer as default application to open .vv file.
2. Open RHV-Manager VM portal and click on VM console.
3. It prompts for application to use for console.

Results:
Download window is only shown when no default behavior is set in the browser. After changing the settings, virt-viewer is used directly skipping the download prompt window.

Verified in:
ovirt-engine-4.4.2.3-0.6.el8ev.noarch
ovirt-web-ui-1.6.4-1.el8ev.noarch
firefox-78.0.2-1.fc31.x86_64

Created attachment 1713354 [details]
downloaded console file name

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat Virtualization security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:3807