Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1640048

Summary: Blank screen with Firefox ESR 60.2.2 using a SSL client certificate
Product: Red Hat Enterprise Virtualization Manager Reporter: Sergio Lopez <slopezpa>
Component: ovirt-web-uiAssignee: Scott Dickerson <sdickers>
Status: CLOSED ERRATA QA Contact: Lukas Svaty <lsvaty>
Severity: high Docs Contact:
Priority: high    
Version: 4.2.6CC: gshereme, lleistne, mgoldboi, sdickers, sgoodman
Target Milestone: ovirt-4.2.8   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-22 12:45:56 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:
Attachments:
Description Flags
[PATCH] branding.js: replace fetch with jquery's ajax none

Description Sergio Lopez 2018-10-17 08:45:06 UTC 
Created attachment 1494768 [details]
[PATCH] branding.js: replace fetch with jquery's ajax

Description of problem:

On an environment configured with an SSL proxy with SSL client authentication ("SSLVerifyClient require" in Apache), trying to open the VM Portal using Firefox ESR 60.2.2 (the only browser available for RHEL6) results in a blank screen. On the other hand, the Administration Portal works without issues.

The browser's webconsole shows this error:

main.6bc4e9be.js:4:17169
 error  '/ovirt-engine/web-ui/branding/fixed-strings.json' cannot be loaded. 
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data

This is apparently caused by a bug in the "fetch" [1] implementation of this version of Firefox, which opens a new HTTPS connection ignoring the SSL client certificate being used by the other connections:

 - Note the third field is a "-":

192.168.159.1 - - [17/Oct/2018:04:03:28 -0400] "GET /ovirt-engine/web-ui/branding/fixed-strings.json HTTP/1.1" 200 136
192.168.159.1 - - [17/Oct/2018:04:04:25 -0400] "GET /ovirt-engine/web-ui/branding/fixed-strings.json HTTP/1.1" 200 136

 - On other connections, that third field is populated with the user corresponding to the certificate SSL_CLIENT_S_DN_CN ("slp" in this example):

192.168.159.1 - slp [17/Oct/2018:04:18:20 -0400] "GET /ovirt-engine/web-ui/branding/fixed-strings.json HTTP/1.1" 200 136
192.168.159.1 - slp [17/Oct/2018:04:35:02 -0400] "GET /ovirt-engine/web-ui/branding/fixed-strings.json HTTP/1.1" 200 136

I know this is a corner case, but since replacing "fetch" with a conventional XHR doesn't have any significant drawback (and there's a single "fetch" in the codebase), please consider applying the patch attached to this BZ.

[1] https://hacks.mozilla.org/2015/03/this-api-is-so-fetching/


Version-Release number of selected component (if applicable):

ovirt-web-ui-1.4.3-1.el7ev


How reproducible:

Always


Steps to Reproduce:
1. Deploy an HTTP Proxy between the clients and the RHV Manager
2. Enable SSL client authentication in the HTTP Proxy, and deploy SSL certificates to the clients.
3. Open the VM Portal using Firefox ESR 60.2.2
Comment 2 Scott Dickerson 2018-10-17 23:02:54 UTC 
https://github.com/oVirt/ovirt-web-ui/pull/834

As per the Fetch API, credentials will not be sent by default with the request [1]. By setting the credentials flag to include instead of the default omit, SSL client certificate authentication will work [2].

[1] = https://fetch.spec.whatwg.org/#concept-request-credentials-mode
[2] = https://stackoverflow.com/questions/39417232/fetch-fails-in-firefox-with-ssl-client-authentication
Comment 3 Scott Dickerson 2018-10-18 13:29:05 UTC 
Backport for 1.4: https://github.com/oVirt/ovirt-web-ui/pull/835
Comment 6 Scott Dickerson 2018-10-19 16:25:30 UTC 
Both PRs have been merged and tested.
Comment 7 Steve Goodman 2019-01-15 12:25:17 UTC 
    If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field.

     

    The documentation team will review, edit, and approve the text.

     

    If this bug does not require doc text, please set the 'requires_doc_text' flag to -.
Comment 9 errata-xmlrpc 2019-01-22 12:45:56 UTC 
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, 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/RHBA-2019:0128