When configuring the jupyter kernel gateway to accept only requests with token in headers and configuring hydrogen like this:
[{"name": "Remote Spark notebook", "options": {"baseUrl": "http://myIp:8888", "ajaxSettings": {"requestHeaders": {"Authorization": "token tokenValue"}}}}]
I'm able to connect to this Remote spark notebook, choose to launch a new session, then choose Python2 kernel for instance, but then:
It looks like if the token authentication is used for the first steps but not for the next ones.
For instance, if the token is wrong in the hydrogen settings, I'm not able to connect & pass the first steps.
So, currently I can connect to the gateway, but not open a kernel.
@fsausset I can reproduce this, but I'm at a loss as to why this is happening. As you can see in the reference above, I've posted on the jupyter-js-services tracker to see if they have any suggestions.
Thansk!
Indeed, it's not clear if it comes from client or server side...
@nikitakit Any news from where it could come from: hydrogen or jupyter-js-services?
I can do some more testing if needed, following your instructions.
As I see it, the issue is somewhere between the jupyter-js-services, jupyter notebook, and jupyter kernel gateway projects. Based on the replies in the issue linked above, there currently isn't any solution other than a change of approach (e.g. using http basic auth via nginx to add security, or maybe using ssh tunneling).
I personally would prefer it if secured connections were transparently handled by an upstream library, instead of requiring hydrogen to package a workaround for this issue.
Connecting to secured servers is definitely a real issue, but I currently lack the bandwidth to code up a solution for it. I'm leaving the github tickets open for now.
(Also, adding a link to https://github.com/nteract/rx-jupyter/issues/15 because it may be relevant)
Thanks for the information and links.
I think that I'll use the http basic auth and wait for a better solution from the jupyter side.
I'm indeed interested in using hydrogen + jupyterHub + authentication when it will be available.
The issue is also there with a basic http auth through a nginx proxy!
I can connect/launch a kernel, but then it's not usable as it's always in "reconnecting" state.
Did you specify the correct values for both baseUrl and wsUrl? See https://github.com/jupyter/kernel_gateway_demos/blob/master/node_client_example/docker-compose.yml#L35
I forgot wsUrl... Basic http auth is now working. Thanks!
To recap the discussion so far: The notebook's password-based auth is not designed to run anywhere other than the browser. Alternative approaches to secure connections include HTTP basic auth, as well as ssh tunneling.
However, I think this situation is quite unsatisfactory. It should really be possible to connect to a notebook server without having to reconfigure the server hosting. I was hoping that the Jupyter folks would eventually enable to a token-based auth system that works for this purpose, but there is no indication that this will happen soon (if at all).
In the meantime I wrote a hydrogen-auth plugin that should enable logging in to notebook servers. Would anyone here be willing to try it out and test if it works? Unfortunately jupyter-js-services doesn't seem to be targeting our usecase, so the code involves some heavy monkey-patching to get things to work.
/cc @lgeiger @rgbkrk
The usage for the plugin is:
Token authentication in jupyter notebook is in progress: https://github.com/jupyter/notebook/pull/1831
/cc @minrk
As for the jupyter-js-services monkey patching, feel free to raise an issue with them to see if they have a way to provide what you need (or a reasonable way to workaround).
Now that #542 is merged, users of notebook server v4.3 (or later) will be able to establish secure connections by specifying a token parameter inside options, e.g. [{"name":"local notebook", "options":{"baseUrl": "http://localhost:8888", "token":"secret"}}]. A big thanks to the upstream teams for addressing this use-case!
Other methods such as hydrogen-auth, http basic auth via proxy, and ssh port forwarding continue to be available. Self-signed certificates remain unsupported for all methods, until https://github.com/nodejs/node/pull/9139 (or https://github.com/nodejs/node/pull/8334) make their way into an Atom release.
I would like to close this issue as resolved. Please let me know if you still have problems using hydrogen with secure servers.
@nikitakit can you please update your comment to have http://localhost:8888 instead of https://localhost:8888? I've just spent half an hour trying to debug why it stopped working after I've copied your line that seemingly differed only in "token": "secret". http seem to be the default for jupyter-notebook
@alesguzik Want to make a pull request to change this?
@lgeiger it is correct in the docs, it's just that while debugging I google-landed at this issue thread, and used code from the comment above. I've asked author to update his comment, so people like me won't spend time trying to figure out what's wrong
:+1: I'll update it
Most helpful comment
Now that #542 is merged, users of notebook server v4.3 (or later) will be able to establish secure connections by specifying a
tokenparameter inside options, e.g.[{"name":"local notebook", "options":{"baseUrl": "http://localhost:8888", "token":"secret"}}]. A big thanks to the upstream teams for addressing this use-case!Other methods such as hydrogen-auth, http basic auth via proxy, and ssh port forwarding continue to be available. Self-signed certificates remain unsupported for all methods, until https://github.com/nodejs/node/pull/9139 (or https://github.com/nodejs/node/pull/8334) make their way into an Atom release.
I would like to close this issue as resolved. Please let me know if you still have problems using hydrogen with secure servers.