[single-host] Preview view does not seem to work in a stable manner (Mixed Content - https / http)

[ibuziuk]

Describe the bug

"Preview" view does not seem to work in a stable manner with single-host

Che version

7.22.0

Steps to reproduce

• Eclipse Che with single-host enabled running with TLS enabled
• Create and start any workspace which exposes run command with preview URL
• Run the app and expose URL for preview
• ERROR: preview view is not loading the app / refresh results in about:blank, navigating to preview URL in the separate browser tab works fine:

Expected behavior

Preview view works and exposes the user app corrctly

Runtime

OpenShift

Logs

Mixed Content: The page at '/dashboard/#/ide/ibuziuk/spring-boot-http-booster-tmayn' was loaded over HTTPS, but requested an insecure frame 'http://routefxwlkq62-ibuziuk-code.apps.sandbox.x8i5.p1.openshiftapps.com/'. This request has been blocked; the content must be served over HTTPS.

[azatsarynnyy]

Two interesting moments here:

• it's single-host but preview URL points to Che sub-domain
• Che is served on https but the generated preview URL is on http

[azatsarynnyy]

I'm not sure how the preview URLs are generated by the Ports Che Plug-in. cc @benoitf

[azatsarynnyy]

It generates https links on my minikube Che instance.

[benoitf]

URLs are generated from there https://github.com/eclipse/che-theia/blob/master/plugins/ports-plugin/src/devfile-handler-che-server-impl.ts

in single host (and maybe openshift), 'user content' is deployed on http and not over https
But in port plugin we're using preview only if there is https content
https://github.com/eclipse/che-theia/blob/master/plugins/ports-plugin/src/endpoints-tree-data-provider.ts#L191-L192

so still investigating if we computer/get a wrong url

[ibuziuk]

just FYI that some devfiles like quarkus seem to expose the preview correctly with single-host:

[sunix]

just FYI that some devfiles like quarkus seem to expose the preview correctly with single-host:

The ones that are working are the one getting through the port plugin. Quarkus was working because of a bug: #18512

[ibuziuk]

@benoitf @azatsarynnyy @skabashnyuk could we assign the issue to the right team and prioritize accordingly. This is a concern for a product and SaaS - https://issues.redhat.com/browse/CRW-1451

[metlos]

We discussed this in the past and concluded that this is an inevitable consequence of running the singlehost mode.

The issue is that we cannot expose the devfile-defined endpoints under a singlehost URL and be confident that it will always work - server-generated absolute URLs certainly won't, the application needs to be agnostic of the webroot, etc.

So we concluded that a separate domain for the devfile-defined endpoints is a must. But that brings along the problem of needing a wildcard certificate should this endpoint be on https - because we cannot know the domain names upfront.

Because we don't want to require wildcard certificates, the endpoint needs to be exposed on HTTP.

But, of course, this brings in the UX issue of the preview pane not working.

Given the reasoning above, we concluded that that is inevitable and we need to work in che-theia to change the UI flow in this usecase to let the user know that a separate window needs to be opened for the preview to work.

[l0rd]

Because we don't want to require wildcard certificates, the endpoint needs to be exposed on HTTP.

Require no, but an option yes.

[metlos]

Because we don't want to require wildcard certificates, the endpoint needs to be exposed on HTTP.

Require no, but an option yes.

But that option would be configured on the che server.

But che-theia needs to work regardless of the option is on or off. So IMHO it really doesn't make a difference, because we need to take into account the fact that there might NOT be a wildcard cert available.

[l0rd]

I mean, in both cases (http or https with untrusted cert), the page won't be rendered in the preview panel. So why actually forcing http?

On the other hand Theia should be smarter and open links in a new tab if it's not able to render it in the preview panel.

[sunix]

We would have cases where admin would have configured a wildcard certificate. So exposing in http is just breaking all the time. Even if you have a wildcard certificate.

We could save that bug in many Che installation.

On the other hand Theia should be smarter and open links in a new tab if it's not able to render it in the preview panel.

The preview panel should render a nice error message with the url link (to open in a new tab).

[azatsarynnyy]

Ports Plug-in should check if Che-Theia is loaded from https AND a preview URL is http - then just open the URL in a dedicated tab without any additional confirmations.

I'm setting area/plugins as the related functionality is in Ports Plug-in + Task Plug-in.

[metlos]

I mean, in both cases (http or https with untrusted cert), the page won't be rendered in the preview panel. So why actually forcing http?

Because with an untrusted cert, you have 1 more hoop to jump through (accepting the security exception in the browser) before you can access the app.

But you're right that we should make this configurable, because encrypted traffic might be required and we would just have to sacrifice a little bit of UX for the additional security.

[sparkoo]

The issue is reported on 7.22. Can we please get it updated to current version with clear steps to reproduce and exact setup (platform, installation, configuration, tls certificate, devfile). I wasn't able to reproduce it on openshift 4.6 with let's encrypt wildcard certificate and golang sample devfile. The endpoint was on https and loaded without any issues in the preview.

[sunix]

@sparkoo you take devsandbox https://codeready-codeready-workspaces-operator.apps.sandbox.x8i5.p1.openshiftapps.com/, with any (but the quarkus one as #18512 has not been applied) get started devfile and run. Just tried with spring one.

[sparkoo]

@sunix I don't know how devsanbox is configured. And what is exact version there? I can see 2.5.0.GA :: crw_2.5/20 :: che-dev @ 9348 (19) :: che-parent @ a6dd7f (7.15.0) :: che @ 7a66a (7.20.2-SNAPSHOT) :: codeready-workspaces @ a1180 (2.5.0.GA) In the footer. So is it 7.15.0 ? Or 7.20.2-SNAPSHOT (really SNAPSHOT)? Or what is really happening there?

[ibuziuk]

Here is the config, it is vanilla CRW 2.5.1

apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: codeready-workspaces
objects:
- apiVersion: org.eclipse.che/v1
  kind: CheCluster
  metadata:
    name: codeready-workspaces
    namespace: ${CHE_NAMESPACE}
  spec:
    auth:
      externalIdentityProvider: false
      openShiftoAuth: true
    database:
      externalDb: false
    metrics:
      enable: true
    server:
      customCheProperties:
        CHE_INFRA_KUBERNETES_NAMESPACE_DEFAULT: <username>-code
        CHE_INFRA_KUBERNETES_NAMESPACE_CREATION__ALLOWED: 'false'
        CHE_INFRA_KUBERNETES_WORKSPACE__UNRECOVERABLE__EVENTS: 'FailedMount,FailedScheduling,MountVolume.SetUp failed,Failed to pull image,FailedCreate,ReplicaSetCreateError'
        CHE_KEYCLOAK_CASCADE__USER__REMOVAL__ENABLED: 'true'
        CHE_SYSTEM_SUPER__PRIVILEGED__MODE: 'true'
        CHE_WORKSPACE_STOP_ROLE_ENABLED: 'true'
      selfSignedCert: false
      serverExposureStrategy: 'single-host'
      tlsSupport: true
      allowUserDefinedWorkspaceNamespaces: false
      cheFlavor: codeready
    storage:
      preCreateSubPaths: true
      pvcClaimSize: 10Gi
      pvcStrategy: common
parameters:
- name: CHE_NAMESPACE
  required: true

[sparkoo]

What che version is CRW 2.5.1 based on? This might be an important fix in che 7.21 #18065

[ibuziuk]

it is based on 7.20.1 AFAIK
So, once we update to 2.6.0 this issue will be fixed automatically?

[sunix]

Works in devsandbox now 👯‍♂️

[ibuziuk]

Looks, like the issue, is fixed in 7.24.2 / CRW 2.6.0
Closing. Thanks, everyone for the input