Make Che Theia webviews work in Che

[mmorhun]

There is a PR in Eclipse Theia which reworks completely webview mechanism.

Some plugins are using webviews (like the Che-Theia welcome page, dependency analytics plugin and many others) and they will be broken (webview content will be empty) once the PR is merged.

According to the new model each webview will have a separate host (usually subdomain of main instance). We need to adapt Che Theia to this changes to make new webviews work in Che.

[skabashnyuk]

Could you please also check that this feature also works on single-host mode.

[mmorhun]

I will try. But last time I had issues with deploying single-host mode, so @skabashnyuk could you please provide precise steps how I can deploy Che multiuser with TLS (self signed cert is ok) single-host instance. Let's suppose that the first step is minikube delete. Thanks.

[tsmaeder]

@mmorhun is it correct to assume that extensions that work in VS Code will work with the new code in Theia? Do we know the places we need to fix in che-theia? How can we tell when our code is broken?

[mmorhun]

@tsmaeder yes VSCode extensions with webview should work in Eclipse Theia in case of using localhost (Otherwise https is required see this comment).
As for now, when new image of Che Theia will be built by our CI, all webviews won't work (For example, welcome page is not displayed).
@AndrienkoAleksandr and I are investigating ways to resolve the problem for Che Theia.

[mmorhun]

For now we are going to set THEIA_WEBVIEW_EXTERNAL_ENDPOINT to the current Che Theia route to have it work as it worked before (no security, though).
Then, to improve security, we'll try to use another route for all webviews (so Theia and all webviews will be separated, but no separation between webviews).

[benoitf]

We might stick to an upstream commit before rewrite of webview support if it takes more than one day to handle problem.

[tsmaeder]

Note that we need that reworked welcome support for Quarkus tooling: #15113. So working around is ok for the moment, but we'll need a solution in the near future.

[mmorhun]

After merging of eclipse-che/che-theia#563 webviews are working again (on the same domain, so no separation (security issue), but this is how it was before) but with new requirement to have Che Theia deployed using SSL (htttps protocol is required).

[mmorhun]

@skabashnyuk could you please provide step by step instruction how to deploy Che in single host mode with SSL? Otherwise I am blocked with single host problem.

[AndrienkoAleksandr]

@skabashnyuk could you please provide step by step instruction how to deploy Che in single host mode with SSL? Otherwise I am blocked with single host problem.

I believe we should create docs for this stuff to share it with everyone...

[skabashnyuk]

https://docs.google.com/document/d/16OUQgXFuWDeH2Fu-je2CVD40JuFcBHbHsO0w5veDo0c/edit

[mmorhun]

To accomplish host separation, I've added another endpoint into Theia editor yaml (in my test environment) which points to the same port:

...
spec:
  endpoints:
   -  name: "theia"
      public: true
      targetPort: 3100
      attributes:
        protocol: http
        type: ide
        secure: true
        cookiesAuthEnabled: true
        discoverable: false
   -  name: "webviews"
      public: true
      targetPort: 3100
      attributes:
        protocol: http
        type: webview
        secure: true
        cookiesAuthEnabled: true
        discoverable: false
...

but Che Master creates only one route for it. In other words, in workspace configuration I see two servers which has identical url, which makes impossible described above approach with separation of Che Theia and webviews hosts. So we need a way to say Che Mater to have two routes to the same target port in workspace pod.

[sparkoo]

cc: @skabashnyuk ^^

[mmorhun]

I faced new problem in separating webviews from Che-Theia. Beside #15430 we have problem with workspace loader.

To explain the problem I must elaborate on some routes details first. Each route in workspace has attributes. Let's consider attributes related to security. They are secure and cookiesAuthEnabled. When secure attribute is set to false this means that the route is completely open and anyone can access it (for this case cookiesAuthEnabled doesn't make sense). If secure is true, Che puts JWT proxy behind the route and JWT proxy allows only authenticated queries. A query considered as authenticated if the request has corresponding token (cookie, header or query parameter with the token). To automate the process of sending token, there is a mechanism that redirects to special page (loader) which sets auth cookie if user are logged in with Keycloak. Then the loader redirects to the target url (and now the auth cookie is set). This mechanism could be turned on by cookiesAuthEnabled attribute of the route. See more in docs.

In case of webviews which are hosted on another from Che-Theia route we have problem with loader (which implements setting the auth cookie). If we have set cookiesAuthEnabled then the request from Theia to webview will fail because Theia (webviews) will get loader code instead of expected response (this works for user in browser as script on loader page sets the cookie and redirects to the target url, which is not possible for just a query). If we turn off cookiesAuthEnabled flag, Theia will fail to get the resources as its queries miss the auth token (cookie). As an attempt to workaround that we may get the token from Che-Theia in some way and set to such requests (which is not good solution), but we cannot do the same for webview content and all requests from webview to their resources will fail (as no one is able to set the token inside plugin code).

@skabashnyuk have I missed something? Do you have an idea what we can do here?

[mmorhun]

I also tried workaround with hidden iframe which does dummy request to webviews route what should set the auth cookie for Theia (webviews frontend host) for webviews route. But it failed with CORS blocking (despite I moved webviews resources serving to the root path):

If set secure flag for the routes to false then everything will work but without any security, of course.

[mmorhun]

Also forgot to mention, if open webviews route manually in browser, it will set the auth cookie and after Che-Theia page refresh webviews are working.

[azatsarynnyy]

I'm closing it as Theia WebViews are working in Che Theia, on the same origin.
Opened a follow-up issue to track the work for isolating the WebViews from Theia page #15616