Document the differences of Che Theia WebView behavior in single-/multi-host modes

[azatsarynnyy]

Is your task related to a problem? Please describe.

There're some differences in Che Theia WebView behavior depending on Che mode - single- or multi-host.
These differences are important to the user. ATM the known differences are:

1. When in a single-host mode, a WebView content is loaded from the same origin as Che Theia, so a WebView has access to Che Theia page's data in a browser
2. Unlike FireFox, Chrome browser requires importing a CA certificate to allow installing a Service Worker for loading a WebView content within Che Theia. It's needed to ensure a secure context.

Describe the solution you'd like

Need to document it in Che/CRW docs.

Describe alternatives you've considered

Additional context

[azatsarynnyy]

We've already discussed the first point - regarding the same origin for Che Theia and a Webview.

The second one we've discovered recently, with @sleshchenko. And I want to gather the opinions on how it's better to document it. This is how it looks to the end-user.

I go to Che URL without Che's self-signed CA certificate imported. Chrome provides the option to proceed with the disabled security check:

I proceed and I'm able to load Che Theia but not a Webview, like the Welcome page.

In the console, Chrome warns me about the security breach:

SecurityError: Failed to register a ServiceWorker for scope ('https://192.168.99.241.nip.io/serverlo8io398-jwtproxy/webviews/webview/') with script ('https://192.168.99.241.nip.io/serverlo8io398-jwtproxy/webviews/webview/service-worker.js'): An SSL certificate error occurred when fetching the script.

Chrome allows installing a ServiceWorker (load a Webview) in a completely secure context only.

For local development/testing Chrome provides a couple of options to disable this check:

1. chrome://flags/#unsafely-treat-insecure-origin-as-secure flag
2. --ignore-certificate-errors cmd parameter for launching the browser

So, there're three options available for the Che/CRW user: two mentioned above + import the self-signed CA certificate into Chrome.

Should we only recommend the user to import a self-signed certificate? Or document all three options at the discretion of the user?
In particular, I'm not sure whether all three are good advice for CRW users.
WDYT? @l0rd @benoitf @sympatheticmoose

[azatsarynnyy]

I believe we can't advise the user to disable the security checks in Chrome, as they are introduced to facilitate local development/testing only.

[l0rd]

@azatsarynnyy it looks like we are back at the initial problem we had with multi-host. In both cases we need to locally import the CA cert if it's untrusted by the local browser. That's annoying. Isn't there an alternative to serviceworker to load webviews?

[azatsarynnyy]

... Isn't there an alternative to serviceworker to load webviews?

@l0rd Service workers are an essential part of Webview API in Theia. It allows handling loading the webview resources (packaged with a plugin) in a very neat/graceful way.
Initially, such architecture comes from VS Code, after they reworked their Electron-based webviews. Then it was adopted by upstream Theia and Che Theia. Now, we’re working on adapting it to our multi-container approach. It’s a true upstream-first way of consuming that part: VS Code > Theia > Che Theia. So, we’re able to get the latest changes relatively cheap.

I agree, asking the user to import a certificate is an annoying step. But I’m not sure if it worth reinventing the wheel yourself by implementing the whole complex mechanism of Webview API in some alternative way and start maintaining it downstream.