Use default user token when running under JupyterHub

[yuvipanda]

When running under a JupyterHub, only the currently running notebook server process is accessible from the browser (via the proxy), so only the token set for the current server will work. Any additional servers running (via jupyter-server-proxy) will still need this token, so multiple servers running in a JupyterHub (a currently unknown pattern) can't work anyway.

So when we are running in a JupyterHub, we just use the provided token in the share URL. No network call is made.

Fixes https://github.com/jupyterlab-contrib/jupyterlab-link-share/issues/10

[yuvipanda]

The test failure seems unrelated?

[jtpio]

The test failure seems unrelated?

Right, this is tracked in https://github.com/jupyter-server/jupyter_releaser/issues/131

[jtpio]

Making a new release with this change.

[consideRatio]

This is related to https://github.com/jupyterhub/jupyterhub/pull/3683 I think. I find the topic quite complicated overall, but here is my attempted summary.

When a user visits JupyterHub with a browser, they are assigned a session id. This session id is planned to be connected to the token in the future (via https://github.com/jupyterhub/jupyterhub/pull/3683), but, this PR will make us make use of a token that was associated with another user's/browser's session id - and that could perhaps break when the JupyterHub behaviour change...

Hmmm, something like that. I'm +1 for this change and such, but I just wanted to highlight there may be issues down the line in this implementation, or maybe not --- I'm not sure: this is so tricky!

[jtpio]

Thanks @consideRatio for the input.

Right, this extension was first created just so we could easily test RTC on the JupyterLab repo, which uses jupyter-server-proxy on Binder to spawn a lab in dev mode. Need to check this is still working with this change.

[jtpio]

@yuvipanda 0.2.2 is out if you want to try it out: https://github.com/jupyterlab-contrib/jupyterlab-link-share/releases/tag/v0.2.2

[yuvipanda]

Based on my understanding of @minrk's comment in https://github.com/jupyterhub/jupyterhub/pull/3683#issuecomment-970186260, that PR landing will break the behavior I am relying on in this PR. Thoughts on how to mitigate this, @minrk?

[yuvipanda]

Thanks @jtpio! I'll wait for #24 to land too before rebuilding :D

[minrk]

It is not true that a token can be assumed to be available in PageConfig when running under JupyterHub, at least not until https://github.com/jupyterlab/jupyterlab_server/pull/220 lands and JupyterHub is updated to make use of it. After that's fixed, though, I'm not sure using that value would be right, but I think you've discussed the "sharing with a token granting you access to become me" in #24).

Prior to JupyterHub 1.5, JupyterLab would always put its server token on the page, which isn't the right token to use, especially in 2.0 with granular permissions. JupyterHub 1.5 disables this, at least when running with jupyter_server, and JupyterLab should disable it as well.

We need https://github.com/jupyterlab/jupyterlab_server/pull/220 to give us a hook to set the token on a per request basis. But this token would not be super appropriate to use in a share link.

[consideRatio]

I've verified this to work with Z2JH 1.1.3 that runs JupyterHub 1.4.2 as a server and with a user environment having JupyterHub 1.5.0 on the image, jupyterlab 3.2.4, and jupyterlab-link-share 0.2.2.