Cannot connect to remote kernel

[tibaes]

I tested the plugin with julia (.jl) and python2 (.py) locally, and it worked.

Now I am trying to use a remote jupyter server, which works in the browser.
As it is in my local network and the notebook is served in the 9999 port, I used the following config:
[{"name": "Remote notebook", "options": {"baseUrl": "http://192.168.2.42:9999/"}}]

When toggled "Hydrogen: Connect to Remote Kernel" / "Remote notebook", just got:
"Connection to gateway failed"

In the server I get in the console:
302 GET /api/kernelspecs?1475697801494
for julia, and another number for python.

My server is inside docker in another computer in the same network, running on ubuntu.
Specifically, I am running my custom jupyter container available in github: https://github.com/scieule/golden-heart

I also tried with https ssl connection, setting the configuration in the jupyter and the baseUrl,
however in this case I got the same error message in the client and nothing happened in the server.
My server notebook was configured to require both self-signed ssl and a password to login.
Maybe hydrogen does not handle these security measures, but I don't know how to test and fix it.

Thanks in advance. This is already my favourite atom plugin! 😄

[nikitakit]

Hydrogen doesn't have any special provisions for opening up a login page, so the only alternative is to try to specify the username/password in the hydrogen config.

We use the jupyter-js-services library to connect to notebook servers, and the idea is that you'll eventually be able to specify a username and password in the options struct. But I'm not sure jupyter-js-services currently has a version of password-based auth that's compatible with the notebook server. You can look at jupyter/services#109 and jupyter/services#205 for details.

Perhaps progress has been made on the above issues, but I'm not up to speed it.

Some alternatives I can think of:

• Not requiring a username/password for the server
• Running an unsecured notebook server on a local port, and then SSH tunneling it to where atom lives
• Using a kernel gateway instead of a notebook server (gateways support token-based auth; more details in the links above)
• Setting up http_basic auth via a proxy, e.g. Basic auth and websocket jupyter/services#158

EDIT: potentially related: jupyter/notebook#325

[tibaes]

Tried passing the password in the configuration, but no success.
So I removed the SSL and the Password configuration of the Jupyter server and now I can connect.

As my local network is safe, I will work this way for now.
I am closing this issue, as the password problem appear to be in the jupyter-js-service, as mentioned above. However, I believe the SSL issue is caused by my self-signed certificate. Contrary to the browser, Atom did not ask me to accept the certificate. With a valid certificate, probably the safe connection could be made, but I don't have a valid one for testing.

[fasiha]

This is a really stupid question, but how do you start jupyter notebook without it requiring a password? Even with a default ~/.jupyter/jupyter_notebook_config.py with the password lines commented out, visiting localhost:8888 (over SSH tunnel) requires a password.

[rgbkrk]

Jupyter started enforcing authentication on vanilla servers by using a temp token.

You could set c.NotebookApp.token='' in your jupyter notebook config on the latest release. That does make your notebook server susceptible to cross site request forgery though, so I don't recommend it. You can also set the token or password directly in the notebook config and then use it.

[nikitakit]

If the notebook is using token auth, it prints something like this when it starts:

The Jupyter Notebook is running at: http://localhost:8889/?token=<token goes here>

In that case, rather than disabling token auth, you should upgrade to the github version of hydrogen and then specify an options.token settings parameter in addition to options.baseUrl.

We should really do a hydrogen release to get this feature out there, and maybe add some docs for it as well.

[lgeiger]

@nikitakit Good point! Tomorrow I'll ship a release 🚀

Yes docs would be excellent.