IPythonViz does not work in Jupyter Notebook that is not on localhost or accessed via HTTPS

[jgosmann]

There is probably a number of problems here, but the first is that browser block non-HTTPS content on HTTPS sites (and they should). That means we should start Nengo GUI in SSL mode, but there a few problems with that:

1. How do we detect if we need to start in SSL mode? The Python code is executed in the IPyKernel that has no knowledge of the frontend accessing it (it could be even multiple frontends). Potentially it is possible to provide both SSL and non-SSL services with a single GUI server (especially given PR Add dual stack IPv6 support. #864). However usually this requires two different ports and then we still do not know which of the two ports to connect to. On the frontend site //some-address should automatically select the right protocol and either port 80 or 443 as used by normal webservers. However, we cannot expect to be able to run Nengo GUI on those ports.
2. Where do we get the SSL certificates from? Ideally we would reuse the ones used for the Jupyter server, but I don't think we can obtain those paths automatically. We could require the user to provide them, but that's inconvenient. It might be possible to auto-generate them, but this requires the user to click through that scary warning about self-signed certificates (and without the user being aware that certificates were generated, they might think of this as suspicious?).

[jgosmann]

I started investigating this issue and updated the description with some information. Comments welcome!

[tbekolay]

You can also get free SSL certs from https://letsencrypt.org/ (and in Python through https://github.com/certbot/certbot). Probably this won't work with localhost, but maybe there's a way around that.

[jgosmann]

Good idea, but it requires the web server to be accessible over the Internet which will rarely be the case.

…

On February 8, 2017 5:40:45 PM EST, Trevor Bekolay ***@***.***> wrote: You can also get free SSL certs from https://letsencrypt.org/ (and in Python through https://github.com/certbot/certbot). Probably this won't work with localhost, but maybe there's a way around that. -- You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: #817 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[jgosmann]

Maybe the best option is to convert IPythonViz into a notebook server extension. That should allow us to read out the notebook SSL certificate files. It might even be possible to hijack the notebook server instead of starting up our own server by registering an appropriate request handler (but the persistent websocket connections might be a problem).

[tbekolay]

convert IPythonViz into a notebook server extension

Sounds promising!

[jgosmann]

The problem with a server extension is that I'm not sure if it is possible to access the kernel to get the model to be displayed.

[jgosmann]

So I am thinking right now that the following approach might work:

• Manage the Nengo GUI server(s) more or less as they are managed now.
• Tunnel requests through the notebook server.

But I have to think more about how to handle authentication (see #867). Probably an authentication token has to be stored in a known place that is only accessible by the user running the notebook server and kernel.

[jgosmann]

I spend a bit mor thought on this, now that there is a PR for token based authentication (#915). There seem to be essentially two possibilities to make IPythonViz work with non-localhost access/SSL.

1. Given that all request to the GUI server need to authenticated in PR Token based authentication #915, we could just listen on all network interfaces. However, it might be surprising to the user that IPythonViz listens for outside connections and it might have some security implications. Outside connections should also require SSL which requires a certificate. It is not clear what the best way to provide such a certificate would be (autogenerate? require it to be passed as argument? list in a global config file?).
2. Requests could be tunneled through the notebook server. That way the notebook's SSL certificate would be used. However, I am uncertain at the moment whether websocket connections can be easily tunneled with the interface provided by Tornado. Also, this requires to tell the requests to the Nengo GUI apart from the normal notebook requests. This could be done by prefixing the paths in the URLs (e.g. https://localhost:8080/viz_component?uid=... would become https://localhost:8080/nengo/viz_component?uid=...). This involves probably changes throughout the whole code base. Furthermore, the tunneling requires the implementation of a notebook server extension and the installation process of those could be improved.

[jgosmann]

From the dev meeting: Prefixing all URL paths in the Nengo GUI shouldn't be a huge issue. So I'm probably look into the tunneling solution first.

[jgosmann]

I put together a proof of concept and tunneling through the notebook server with a notebook server extension does work! 😃 Found also some minor bugs with certain clients in the process. PRs forthcoming.