58dccdb59b
mostly a copy (fork) of singleuser app using public APIs instead of lots of patching. opt-in via `JUPYTERHUB_SINGLEUSER_EXTENSION=1` related changes: - stop running a test single-user server in a thread. It's complicated and fragile. Instead, run it normally, and get the info we need from a custom handler registered via an extension via the `full_spawn` fixture
Granting read-only access to user servers
Jupyter Server 2.0 adds the ability to enforce granular permissions via its Authorizer API. Combining this with JupyterHub's custom scopes and singleuser-server extension, you can use JupyterHub to grant users restricted (e.g. read-only) access to each others' servers, rather than an all-or-nothing access permission.
This example demonstrates granting read-only access to just one specific user's server to one specific other user,
but you can grant access for groups, all users, etc.
Given users vex and percy, we want vex to have permission to:
- read and open files, and view the state of the server, but
- not write or edit files
- not start/stop the server
- not execute anything
(Jupyter Server's Authorizer API allows for even more fine-grained control)
To test this, you'll want two browser sessions:
- login as
percy(dummy auth means username and no password needed) and start the server - in another session (another browser, or logout as percy), login as
vex(again, any password in the example) - as vex, visit http://127.0.0.1:8000/users/percy/
Percy can use their server as normal, but vex will only be able to read files. Vex won't be able to run any code, connect to kernels, or save edits to files.