mirror of
https://github.com/jupyterhub/jupyterhub.git
synced 2025-10-12 12:33:02 +00:00
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
26 lines
1.3 KiB
Markdown
26 lines
1.3 KiB
Markdown
# 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:
|
|
|
|
1. read and open files, and view the state of the server, but
|
|
2. not write or edit files
|
|
3. not start/stop the server
|
|
4. not execute anything
|
|
|
|
(Jupyter Server's Authorizer API allows for even more fine-grained control)
|
|
|
|
To test this, you'll want two browser sessions:
|
|
|
|
1. login as `percy` (dummy auth means username and no password needed) and start the server
|
|
2. in another session (another browser, or logout as percy), login as `vex` (again, any password in the example)
|
|
3. 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.
|