jupyter notebook does not open in webview from remote in python-docker image

[mridup]

Jupyter notebook does not open in webview when notebook is opened from remote browser.
However the same python notebook can be opened when it is opened from browser running on same host (localhost).
There is no proxy configured and both host and remote machines are different machines running on same local network.

python-docker Dockerfile was modified to install (pip install) jupyter, notebook, ipython, ipykernel etc.
The error is either:
"server IP address could not be found" or
"server did not send any data"

Another fact is that if a jupyter notebook is run manually inside the container: "jupyter notebook --ip 0.0.0.0 --allow-root", then the jupyter notebook can be accessed from remote browser. The issue seems only with the notebook running inside the webview or maybe the webview itself is somehow not reachable from remote?

Here is an image:

[vince-fugnitto]

@mridup I believe it is expected, you will need to configure your remote host, please see the changelog for additional information:

Some additional information:

• https://spectrum.chat/theia/dev/any-breaking-changes-made-recently-to-webview~e5bd31a3-eee7-4288-b092-cf7407468780
• [core] Cannot render webviews when theia is behind a reverse-proxy eclipse-theia/theia#7484
• https://spectrum.chat/theia/theiadevcon/need-help-updating-theia-core-and-deploying-it-to-a-docker-container~65a8f6ac-3f36-4eb8-b68f-9647b34475e8

[marcdumais-work]

@marechal-p Could you also chime-in? In addition to what @vince-fugnitto provided, there is also a network aspect to this, with the webview URL needing to resolve correctly so that clients can find the content.

One thing to consider: our webviews use web workers that I think require SSL to work. So you may need to wrap the image with something like our theia-https-docker example: https://github.com/theia-ide/theia-apps/tree/master/theia-https-docker#how-to-use or otherwise generate a SSL cert in your version of the image and start the Theia app in HTTPS mode, pointing to the certificate.

[mridup]

Thanks @vince-fugnitto and @marcdumais-work for your comments.
Forgive my unfamiliarity with theia in general.

From what I understood was that:

1. we could move to unsecure mode by configuring THEIA_WEBVIEW_EXTERNAL_ENDPOINT as {{hostname}}
2. but then as @marcdumais-work says, we cannot have unsecure mode with a remote host since webviews use service workers and service workers will require SSL.

I tried (1) above without wrapping the docker image in https (gen-https-proxy) but this results in following error when we try to open a jupyter notebook:

But above is expected because of (2)

Just wrapping the image in https as suggested @ https://github.com/theia-ide/theia-apps/tree/master/theia-https-docker#how-to-use but without configuring THEIA_WEBVIEW_EXTERNAL_ENDPOINT as {{hostname}} within the container and then opening a jupyter notebook yields the following error:

Not sure if above is a related error to web workers or something else.

Can you please point to what is not understood or what is missing?

[mridup]

this comment from @akosyakov eclipse-theia/theia#6465 (comment)
seems to suggest that it is possible to configure THEIA_WEBVIEW_EXTERNAL_ENDPOINT as {{hostname}} and together with https it should work?

[paul-marechal]

@mridup yes it should work. But note that doing so will result in all webviews sharing the same origin, which means they'll share a lot of context (cookies, localstorage, etc...). If possible you want the webviews to be hosted on different origins like it is done by default. My current conclusion is that you would need some kind of DNS configuration to be able to resolve those random sub-domains.

[mridup]

running an image with ENV THEIA_WEBVIEW_EXTERNAL_ENDPOINT set to {{hostname}} and then wrapping the image in another https-docker with self signed certificates did not work either...However loading the notebook doesn't even load the webview perhaps as it just loads the file in text format and then there seems to be an empty tab (perhaps the webview tab). There is no error evident in the chrome network or console views...

[mridup]

@marechal-p at the moment the use-case is contrived and in fact the theia host and it's client will all be in the same private network. For DNS config, something like a reverse proxy and certificates with wild card certificates for subdomains could work maybe.

[marcdumais-work]

Hi @mridup ,

Not sure if that might be the problem, but IIRC some browsers (Firefox?) seem to give deeper scrutiny before considering a host secure, for the purpose of using web workers, and may not be satisfied with a self-signed certificate. If you happen to be using Firefox, please also try with e.g. Chromium, just to confirm.

Also note that jupyter notebooks are known to have issues in Theia still, though things are slowly improving. So it may be you're reaching the limits of what's known to work at this time.

https://github.com/eclipse-theia/theia/issues?q=is%3Aissue+is%3Aopen+jupyter+

For that, I may suggest making sure that whatever you want to do works locally first, e.g. in the browser or Electron version of the Theia example application or such.

[mridup]

Hi @marcdumais-work ,
I am using only Chrome as the browser. The host where theia container is running is Linux. The client I have tried to access from is a Windows machine and I have tried to access from a Mac as well. All the machines are attached to the same wireless network (no proxy, home network).

Surprisingly now that you mentioned about trying locally:
When running theia container with WEBVIEW configured as {{hostname}} and wrapped in https-docker image:

• Locally open python notebook: does not work (behaviour described earlier)

• Remote machine open python notebook: does not work (same behaviour as locally)

When running theia container without any configuration (webview with unique origin):

• Locally open python notebook: works fine

• Remote machine open python notebook: does not work (as described in first post)

[marcdumais-work]

When running theia container

@mridup I should have been clearer: by "locally" I meant not in docker. Maybe "natively" would have been more precise. Basically remove the docker aspect from the equation, and first make sure what you want to do works in a plain Electron or Browser Theia application, running and accessed from localhost.

[mridup]

Hi @vince-fugnitto , @marcdumais-work , @marechal-p ,
thanks for your inputs and comments.
Update:
I tested an Azure ACI domain with letsencrypt certificates and started theia with ssl command pointing to said certificates. ( Also to note that self-signed certificates don't work as service workers complain in chrome with self-signed certificates)
I am now able to load jupyter notebooks from this domain. Theia container is configured with THEIA_WEBVIEW_EXTERNAL_ENDPOINT set to {{hostname}} as discussed before.

So in closing, CA certficates are a must to get the service workers working within the webview (as pointed out @marcdumais-work )
Unique origin with .webview. URIs will probably need wildcards with some reverse proxy redirecting to correct destinations. But this has to be tested yet.

Access through Nginx redirection still does not work at the moment for me, e.g: mpd-ca-ssl.westeurope.azurecontainer.io/theia but this is definitely a configuration issue in nginx I think.