search

jupyterlab-contrib / jupyterlab-link-share

JupyterLab Extension to easily share a link to a running server on Binder
BSD 3-Clause "New" or "Revised" License
53 stars 14 forks source link

Add option to disable impersonation token #54

Open minrk opened 1 year ago

minrk commented 1 year ago

Is your feature request related to a problem? Please describe.

jupyterlab-link-share currently extracts the current user's access token and appends it to the URL. In a single jupyterlab instance this makes sense. It gets sketchy in JupyterHub >= 2, where we have permissions for granting users access to each others servers, which the token bypasses and is essentially a token for impersonating the link sharer (only for talking to the current server).

Describe the solution you'd like

Add an option, ideally controllable in server-side config, to omit the token from the URL so that regular JupyterHub access controls are applied instead of sharing a token for impersonation.

There are 3 reasonable links to share in a JupyterHub context:

  1. link to this server, including token for auth (definitely makes sense for standalone servers, sometimes in JupyterHub though deployments may want to prohibit it)
  2. link to this server, no token (shareable link, relies on other auth channels such as JupyterHub auth or a known password)
  3. link to the same file on a shared filesystem, on the user's own server

JupyterLab's built-in 'copy shareable link' does 3, while this extension does 1. But what seems to be missing is 2 (often, copying the URL from the browser will do this. I don't know how often).

In the age of RTC and JupyterHub access permissions, it makes sense to switch between 1 and 2. Some deployments may want only 2 to be allowed.

I see two main options:

  1. single bool flag to switch between 1 and 2 that JupyterHub deployments can pick via config (writing user-settings may be enough)
  2. expose this complexity to users, so they choose at share-time which link to create, and can pick from all 3 (3 only being available when run from a hub).

In some ways, 2. is the simplest, but it puts a decision in the hands of a person who may not have the right information to make it. It's up to the deployment whether 2 will work (do users have permission to access each others' servers?) and 3 (are they even on a shared filesystem?), and the deployment may even want to prohibit 1 by policy (it can't prevent it, technically). Users may well not know whether any of these will work, and the extension has no way to figure any of them out for itself.

Describe alternatives you've considered

Rely on JupyterLab's built-in "copy shareable link", which does the correct thing leaving the token out, but by default uses the user-redirect URL to send users to the same file on their own server (assuming a shared filesystem).

Additional context

fperez commented 1 year ago

Ping both @balajialg and @yuvipanda - I think this is something we'll want across a bunch of hubs we're concerned with, whether at Berkeley or in collaborative settings like JMTE and CryoCloud.

I'm going to use link-share as-is in Stat159 as discussed yesterday with @ryanlovett and @facusapienza21: we have a controlled environment that's small enough for me to be willing to do this, and given that:

  1. Users still have to initiate the sharing action.
  2. Stopping/restarting their server is annoying but not a major problem.

I think we can deal with it. But this is highly sub-optimal and not at all advisable in any other deployment, so I hope we can get a sharing mechanism with improved security controls soon. It will greatly improve our chances of getting wider adoption/testing of the RTC machinery (I know this has uses beyond RTC, but the existence of RTC is a massive motivator to use these tools).

Thanks all for the great work on this, btw!! It's amazing what this will enable us to do :)