mirror of
https://github.com/jupyterhub/jupyterhub.git
synced 2025-10-17 23:13:00 +00:00
run pre-commit (prettier)
This commit is contained in:
Min RK
@@ -89,7 +89,6 @@ class DictionaryAuthenticator(Authenticator):
|
||||
return data['username']
|
||||
```
|
||||
|
||||
|
||||
#### Normalize usernames
|
||||
|
||||
Since the Authenticator and Spawner both use the same username,
|
||||
@@ -111,11 +110,10 @@ When using `PAMAuthenticator`, you can set
|
||||
normalize usernames using PAM (basically round-tripping them: username
|
||||
to uid to username), which is useful in case you use some external
|
||||
service that allows multiple usernames mapping to the same user (such
|
||||
as ActiveDirectory, yes, this really happens). When
|
||||
`pam_normalize_username` is on, usernames are *not* normalized to
|
||||
as ActiveDirectory, yes, this really happens). When
|
||||
`pam_normalize_username` is on, usernames are _not_ normalized to
|
||||
lowercase.
|
||||
|
||||
|
||||
#### Validate usernames
|
||||
|
||||
In most cases, there is a very limited set of acceptable usernames.
|
||||
@@ -132,7 +130,6 @@ To only allow usernames that start with 'w':
|
||||
c.Authenticator.username_pattern = r'w.*'
|
||||
```
|
||||
|
||||
|
||||
### How to write a custom authenticator
|
||||
|
||||
You can use custom Authenticator subclasses to enable authentication
|
||||
@@ -145,7 +142,6 @@ and [post_spawn_stop(user, spawner)][], are hooks that can be used to do
|
||||
auth-related startup (e.g. opening PAM sessions) and cleanup
|
||||
(e.g. closing PAM sessions).
|
||||
|
||||
|
||||
See a list of custom Authenticators [on the wiki](https://github.com/jupyterhub/jupyterhub/wiki/Authenticators).
|
||||
|
||||
If you are interested in writing a custom authenticator, you can read
|
||||
@@ -186,7 +182,6 @@ Additionally, configurable attributes for your authenticator will
|
||||
appear in jupyterhub help output and auto-generated configuration files
|
||||
via `jupyterhub --generate-config`.
|
||||
|
||||
|
||||
### Authentication state
|
||||
|
||||
JupyterHub 0.8 adds the ability to persist state related to authentication,
|
||||
@@ -220,12 +215,10 @@ To store auth_state, two conditions must be met:
|
||||
export JUPYTERHUB_CRYPT_KEY=$(openssl rand -hex 32)
|
||||
```
|
||||
|
||||
|
||||
JupyterHub uses [Fernet](https://cryptography.io/en/latest/fernet/) to encrypt auth_state.
|
||||
To facilitate key-rotation, `JUPYTERHUB_CRYPT_KEY` may be a semicolon-separated list of encryption keys.
|
||||
If there are multiple keys present, the **first** key is always used to persist any new auth_state.
|
||||
|
||||
|
||||
#### Using auth_state
|
||||
|
||||
Typically, if `auth_state` is persisted it is desirable to affect the Spawner environment in some way.
|
||||
@@ -266,11 +259,10 @@ PAM session.
|
||||
|
||||
Beginning with version 0.8, JupyterHub is an OAuth provider.
|
||||
|
||||
|
||||
[Authenticator]: https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/auth.py
|
||||
[PAM]: https://en.wikipedia.org/wiki/Pluggable_authentication_module
|
||||
[OAuth]: https://en.wikipedia.org/wiki/OAuth
|
||||
[GitHub OAuth]: https://developer.github.com/v3/oauth/
|
||||
[OAuthenticator]: https://github.com/jupyterhub/oauthenticator
|
||||
[authenticator]: https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/auth.py
|
||||
[pam]: https://en.wikipedia.org/wiki/Pluggable_authentication_module
|
||||
[oauth]: https://en.wikipedia.org/wiki/OAuth
|
||||
[github oauth]: https://developer.github.com/v3/oauth/
|
||||
[oauthenticator]: https://github.com/jupyterhub/oauthenticator
|
||||
[pre_spawn_start(user, spawner)]: https://jupyterhub.readthedocs.io/en/latest/api/auth.html#jupyterhub.auth.Authenticator.pre_spawn_start
|
||||
[post_spawn_stop(user, spawner)]: https://jupyterhub.readthedocs.io/en/latest/api/auth.html#jupyterhub.auth.Authenticator.post_spawn_stop
|
||||
|
||||
@@ -3,18 +3,17 @@
|
||||
In this example, we show a configuration file for a fairly standard JupyterHub
|
||||
deployment with the following assumptions:
|
||||
|
||||
* Running JupyterHub on a single cloud server
|
||||
* Using SSL on the standard HTTPS port 443
|
||||
* Using GitHub OAuth (using oauthenticator) for login
|
||||
* Using the default spawner (to configure other spawners, uncomment and edit
|
||||
- Running JupyterHub on a single cloud server
|
||||
- Using SSL on the standard HTTPS port 443
|
||||
- Using GitHub OAuth (using oauthenticator) for login
|
||||
- Using the default spawner (to configure other spawners, uncomment and edit
|
||||
`spawner_class` as well as follow the instructions for your desired spawner)
|
||||
* Users exist locally on the server
|
||||
* Users' notebooks to be served from `~/assignments` to allow users to browse
|
||||
- Users exist locally on the server
|
||||
- Users' notebooks to be served from `~/assignments` to allow users to browse
|
||||
for notebooks within other users' home directories
|
||||
* You want the landing page for each user to be a `Welcome.ipynb` notebook in
|
||||
- You want the landing page for each user to be a `Welcome.ipynb` notebook in
|
||||
their assignments directory.
|
||||
* All runtime files are put into `/srv/jupyterhub` and log files in `/var/log`.
|
||||
|
||||
- All runtime files are put into `/srv/jupyterhub` and log files in `/var/log`.
|
||||
|
||||
The `jupyterhub_config.py` file would have these settings:
|
||||
|
||||
|
||||
@@ -6,12 +6,12 @@ SSL port `443`. This could be useful if the JupyterHub server machine is also
|
||||
hosting other domains or content on `443`. The goal in this example is to
|
||||
satisfy the following:
|
||||
|
||||
* JupyterHub is running on a server, accessed *only* via `HUB.DOMAIN.TLD:443`
|
||||
* On the same machine, `NO_HUB.DOMAIN.TLD` strictly serves different content,
|
||||
- JupyterHub is running on a server, accessed _only_ via `HUB.DOMAIN.TLD:443`
|
||||
- On the same machine, `NO_HUB.DOMAIN.TLD` strictly serves different content,
|
||||
also on port `443`
|
||||
* `nginx` or `apache` is used as the public access point (which means that
|
||||
only nginx/apache will bind to `443`)
|
||||
* After testing, the server in question should be able to score at least an A on the
|
||||
- `nginx` or `apache` is used as the public access point (which means that
|
||||
only nginx/apache will bind to `443`)
|
||||
- After testing, the server in question should be able to score at least an A on the
|
||||
Qualys SSL Labs [SSL Server Test](https://www.ssllabs.com/ssltest/)
|
||||
|
||||
Let's start out with needed JupyterHub configuration in `jupyterhub_config.py`:
|
||||
@@ -144,6 +144,7 @@ Now restart `nginx`, restart the JupyterHub, and enjoy accessing
|
||||
`https://NO_HUB.DOMAIN.TLD`.
|
||||
|
||||
### SELinux permissions for nginx
|
||||
|
||||
On distributions with SELinux enabled (e.g. Fedora), one may encounter permission errors
|
||||
when the nginx service is started.
|
||||
|
||||
@@ -155,8 +156,8 @@ semanage port -a -t http_port_t -p tcp 8000
|
||||
setsebool -P httpd_can_network_relay 1
|
||||
setsebool -P httpd_can_network_connect 1
|
||||
```
|
||||
Replace 8000 with the port the jupyterhub server is running from.
|
||||
|
||||
Replace 8000 with the port the jupyterhub server is running from.
|
||||
|
||||
## Apache
|
||||
|
||||
@@ -211,22 +212,24 @@ Listen 443
|
||||
</VirtualHost>
|
||||
```
|
||||
|
||||
|
||||
In case of the need to run the jupyterhub under /jhub/ or other location please use the below configurations:
|
||||
|
||||
- JupyterHub running locally at http://127.0.0.1:8000/jhub/ or other location
|
||||
|
||||
httpd.conf amendments:
|
||||
|
||||
```bash
|
||||
RewriteRule /jhub/(.*) ws://127.0.0.1:8000/jhub/$1 [NE.P,L]
|
||||
RewriteRule /jhub/(.*) http://127.0.0.1:8000/jhub/$1 [NE,P,L]
|
||||
|
||||
|
||||
ProxyPass /jhub/ http://127.0.0.1:8000/jhub/
|
||||
ProxyPassReverse /jhub/ http://127.0.0.1:8000/jhub/
|
||||
```
|
||||
|
||||
```
|
||||
|
||||
jupyterhub_config.py amendments:
|
||||
```bash
|
||||
--The public facing URL of the whole JupyterHub application.
|
||||
--This is the address on which the proxy will bind. Sets protocol, ip, base_url
|
||||
c.JupyterHub.bind_url = 'http://127.0.0.1:8000/jhub/'
|
||||
```
|
||||
|
||||
```bash
|
||||
--The public facing URL of the whole JupyterHub application.
|
||||
--This is the address on which the proxy will bind. Sets protocol, ip, base_url
|
||||
c.JupyterHub.bind_url = 'http://127.0.0.1:8000/jhub/'
|
||||
```
|
||||
|
||||
@@ -9,7 +9,7 @@ Only do this if you are very sure you must.
|
||||
There are many Authenticators and Spawners available for JupyterHub. Some, such
|
||||
as DockerSpawner or OAuthenticator, do not need any elevated permissions. This
|
||||
document describes how to get the full default behavior of JupyterHub while
|
||||
running notebook servers as real system users on a shared system without
|
||||
running notebook servers as real system users on a shared system without
|
||||
running the Hub itself as root.
|
||||
|
||||
Since JupyterHub needs to spawn processes as other users, the simplest way
|
||||
@@ -50,10 +50,9 @@ To do this we add to `/etc/sudoers` (use `visudo` for safe editing of sudoers):
|
||||
|
||||
- specify the list of users `JUPYTER_USERS` for whom `rhea` can spawn servers
|
||||
- set the command `JUPYTER_CMD` that `rhea` can execute on behalf of users
|
||||
- give `rhea` permission to run `JUPYTER_CMD` on behalf of `JUPYTER_USERS`
|
||||
- give `rhea` permission to run `JUPYTER_CMD` on behalf of `JUPYTER_USERS`
|
||||
without entering a password
|
||||
|
||||
|
||||
For example:
|
||||
|
||||
```bash
|
||||
@@ -91,16 +90,16 @@ $ adduser -G jupyterhub newuser
|
||||
Test that the new user doesn't need to enter a password to run the sudospawner
|
||||
command.
|
||||
|
||||
This should prompt for your password to switch to rhea, but *not* prompt for
|
||||
This should prompt for your password to switch to rhea, but _not_ prompt for
|
||||
any password for the second switch. It should show some help output about
|
||||
logging options:
|
||||
|
||||
```bash
|
||||
$ sudo -u rhea sudo -n -u $USER /usr/local/bin/sudospawner --help
|
||||
Usage: /usr/local/bin/sudospawner [OPTIONS]
|
||||
|
||||
|
||||
Options:
|
||||
|
||||
|
||||
--help show this help information
|
||||
...
|
||||
```
|
||||
@@ -151,12 +150,13 @@ We want our new user to be able to read the shadow passwords, so add it to the s
|
||||
$ sudo usermod -a -G shadow rhea
|
||||
```
|
||||
|
||||
If you want jupyterhub to serve pages on a restricted port (such as port 80 for http),
|
||||
If you want jupyterhub to serve pages on a restricted port (such as port 80 for http),
|
||||
then you will need to give `node` permission to do so:
|
||||
|
||||
```bash
|
||||
sudo setcap 'cap_net_bind_service=+ep' /usr/bin/node
|
||||
```
|
||||
|
||||
However, you may want to further understand the consequences of this.
|
||||
|
||||
You may also be interested in limiting the amount of CPU any process can use
|
||||
@@ -165,7 +165,6 @@ distributions' packaging system. This can be used to keep any user's process
|
||||
from using too much CPU cycles. You can configure it accoring to [these
|
||||
instructions](http://ubuntuforums.org/showthread.php?t=992706).
|
||||
|
||||
|
||||
### Shadow group (FreeBSD)
|
||||
|
||||
**NOTE:** This has not been tested and may not work as expected.
|
||||
@@ -186,7 +185,7 @@ $ sudo chgrp shadow /etc/master.passwd
|
||||
$ sudo chmod g+r /etc/master.passwd
|
||||
```
|
||||
|
||||
We want our new user to be able to read the shadow passwords, so add it to the
|
||||
We want our new user to be able to read the shadow passwords, so add it to the
|
||||
shadow group:
|
||||
|
||||
```bash
|
||||
@@ -220,7 +219,7 @@ Finally, start the server as our newly configured user, `rhea`:
|
||||
```bash
|
||||
$ cd /etc/jupyterhub
|
||||
$ sudo -u rhea jupyterhub --JupyterHub.spawner_class=sudospawner.SudoSpawner
|
||||
```
|
||||
```
|
||||
|
||||
And try logging in.
|
||||
|
||||
@@ -228,7 +227,7 @@ And try logging in.
|
||||
|
||||
If you still get a generic `Permission denied` `PermissionError`, it's possible SELinux is blocking you.
|
||||
Here's how you can make a module to allow this.
|
||||
First, put this in a file named `sudo_exec_selinux.te`:
|
||||
First, put this in a file named `sudo_exec_selinux.te`:
|
||||
|
||||
```bash
|
||||
module sudo_exec_selinux 1.1;
|
||||
|
||||
@@ -22,20 +22,18 @@ This section will focus on user environments, including:
|
||||
- Installing kernelspecs
|
||||
- Using containers vs. multi-user hosts
|
||||
|
||||
|
||||
## Installing packages
|
||||
|
||||
To make packages available to users, you generally will install packages
|
||||
system-wide or in a shared environment.
|
||||
|
||||
This installation location should always be in the same environment that
|
||||
`jupyterhub-singleuser` itself is installed in, and must be *readable and
|
||||
executable* by your users. If you want users to be able to install additional
|
||||
packages, it must also be *writable* by your users.
|
||||
`jupyterhub-singleuser` itself is installed in, and must be _readable and
|
||||
executable_ by your users. If you want users to be able to install additional
|
||||
packages, it must also be _writable_ by your users.
|
||||
|
||||
If you are using a standard system Python install, you would use:
|
||||
|
||||
|
||||
```bash
|
||||
sudo python3 -m pip install numpy
|
||||
```
|
||||
@@ -47,7 +45,6 @@ You may also use conda to install packages. If you do, you should make sure
|
||||
that the conda environment has appropriate permissions for users to be able to
|
||||
run Python code in the env.
|
||||
|
||||
|
||||
## Configuring Jupyter and IPython
|
||||
|
||||
[Jupyter](https://jupyter-notebook.readthedocs.io/en/stable/config_overview.html)
|
||||
@@ -64,6 +61,7 @@ users. It's generally more efficient to configure user environments "system-wide
|
||||
and it's a good idea to avoid creating files in users' home directories.
|
||||
|
||||
The typical locations for these config files are:
|
||||
|
||||
- **system-wide** in `/etc/{jupyter|ipython}`
|
||||
- **env-wide** (environment wide) in `{sys.prefix}/etc/{jupyter|ipython}`.
|
||||
|
||||
@@ -91,7 +89,6 @@ c.MappingKernelManager.cull_idle_timeout = 20 * 60
|
||||
c.MappingKernelManager.cull_interval = 2 * 60
|
||||
```
|
||||
|
||||
|
||||
## Installing kernelspecs
|
||||
|
||||
You may have multiple Jupyter kernels installed and want to make sure that
|
||||
@@ -119,7 +116,6 @@ sure are available, I can install their specs system-wide (in /usr/local) with:
|
||||
/path/to/python2 -m IPython kernel install --prefix=/usr/local
|
||||
```
|
||||
|
||||
|
||||
## Multi-user hosts vs. Containers
|
||||
|
||||
There are two broad categories of user environments that depend on what
|
||||
@@ -141,8 +137,8 @@ When JupyterHub uses **container-based** Spawners (e.g. KubeSpawner or
|
||||
DockerSpawner), the 'system-wide' environment is really the container image
|
||||
which you are using for users.
|
||||
|
||||
In both cases, you want to *avoid putting configuration in user home
|
||||
directories* because users can change those configuration settings. Also,
|
||||
In both cases, you want to _avoid putting configuration in user home
|
||||
directories_ because users can change those configuration settings. Also,
|
||||
home directories typically persist once they are created, so they are
|
||||
difficult for admins to update later.
|
||||
|
||||
|
||||
@@ -46,8 +46,8 @@ additional configuration required for MySQL that is not needed for PostgreSQL.
|
||||
|
||||
- You should use the `pymysql` sqlalchemy provider (the other one, MySQLdb,
|
||||
isn't available for py3).
|
||||
- You also need to set `pool_recycle` to some value (typically 60 - 300)
|
||||
which depends on your MySQL setup. This is necessary since MySQL kills
|
||||
- You also need to set `pool_recycle` to some value (typically 60 - 300)
|
||||
which depends on your MySQL setup. This is necessary since MySQL kills
|
||||
connections serverside if they've been idle for a while, and the connection
|
||||
from the hub will be idle for longer than most connections. This behavior
|
||||
will lead to frustrating 'the connection has gone away' errors from
|
||||
|
||||
@@ -54,7 +54,7 @@ class MyProxy(Proxy):
|
||||
"""Stop the proxy"""
|
||||
```
|
||||
|
||||
These methods **may** be coroutines.
|
||||
These methods **may** be coroutines.
|
||||
|
||||
`c.Proxy.should_start` is a configurable flag that determines whether the
|
||||
Hub should call these methods when the Hub itself starts and stops.
|
||||
@@ -103,7 +103,7 @@ route to be proxied, such as `/user/name/`. A routespec will:
|
||||
|
||||
When adding a route, JupyterHub may pass a JSON-serializable dict as a `data`
|
||||
argument that should be attached to the proxy route. When that route is
|
||||
retrieved, the `data` argument should be returned as well. If your proxy
|
||||
retrieved, the `data` argument should be returned as well. If your proxy
|
||||
implementation doesn't support storing data attached to routes, then your
|
||||
Python wrapper may have to handle storing the `data` piece itself, e.g in a
|
||||
simple file or database.
|
||||
@@ -136,7 +136,7 @@ async def delete_route(self, routespec):
|
||||
|
||||
### Retrieving routes
|
||||
|
||||
For retrieval, you only *need* to implement a single method that retrieves all
|
||||
For retrieval, you only _need_ to implement a single method that retrieves all
|
||||
routes. The return value for this function should be a dictionary, keyed by
|
||||
`routespect`, of dicts whose keys are the same three arguments passed to
|
||||
`add_route` (`routespec`, `target`, `data`)
|
||||
|
||||
@@ -169,7 +169,7 @@ curl -X POST -H "Authorization: token <token>" "http://127.0.0.1:8081/hub/api/us
|
||||
```
|
||||
|
||||
With the named-server functionality, it's now possible to launch more than one
|
||||
specifically named servers against a given user. This could be used, for instance,
|
||||
specifically named servers against a given user. This could be used, for instance,
|
||||
to launch each server based on a different image.
|
||||
|
||||
First you must enable named-servers by including the following setting in the `jupyterhub_config.py` file.
|
||||
@@ -187,6 +187,7 @@ hub:
|
||||
```
|
||||
|
||||
With that setting in place, a new named-server is activated like this:
|
||||
|
||||
```bash
|
||||
curl -X POST -H "Authorization: token <token>" "http://127.0.0.1:8081/hub/api/users/<user>/servers/<serverA>"
|
||||
curl -X POST -H "Authorization: token <token>" "http://127.0.0.1:8081/hub/api/users/<user>/servers/<serverB>"
|
||||
@@ -201,7 +202,6 @@ will need to be able to handle the case of multiple servers per user and ensure
|
||||
uniqueness of names, particularly if servers are spawned via docker containers
|
||||
or kubernetes pods.
|
||||
|
||||
|
||||
## Learn more about the API
|
||||
|
||||
You can see the full [JupyterHub REST API][] for details. This REST API Spec can
|
||||
@@ -210,6 +210,6 @@ Both resources contain the same information and differ only in its display.
|
||||
Note: The Swagger specification is being renamed the [OpenAPI Initiative][].
|
||||
|
||||
[interactive style on swagger's petstore]: http://petstore.swagger.io/?url=https://raw.githubusercontent.com/jupyterhub/jupyterhub/master/docs/rest-api.yml#!/default
|
||||
[OpenAPI Initiative]: https://www.openapis.org/
|
||||
[JupyterHub REST API]: ./rest-api
|
||||
[Jupyter Notebook REST API]: http://petstore.swagger.io/?url=https://raw.githubusercontent.com/jupyter/notebook/master/notebook/services/api/api.yaml
|
||||
[openapi initiative]: https://www.openapis.org/
|
||||
[jupyterhub rest api]: ./rest-api
|
||||
[jupyter notebook rest api]: http://petstore.swagger.io/?url=https://raw.githubusercontent.com/jupyter/notebook/master/notebook/services/api/api.yaml
|
||||
|
||||
@@ -1,28 +1,26 @@
|
||||
# Running proxy separately from the hub
|
||||
|
||||
|
||||
## Background
|
||||
|
||||
The thing which users directly connect to is the proxy, by default
|
||||
`configurable-http-proxy`. The proxy either redirects users to the
|
||||
`configurable-http-proxy`. The proxy either redirects users to the
|
||||
hub (for login and managing servers), or to their own single-user
|
||||
servers. Thus, as long as the proxy stays running, access to existing
|
||||
servers. Thus, as long as the proxy stays running, access to existing
|
||||
servers continues, even if the hub itself restarts or goes down.
|
||||
|
||||
When you first configure the hub, you may not even realize this
|
||||
because the proxy is automatically managed by the hub. This is great
|
||||
because the proxy is automatically managed by the hub. This is great
|
||||
for getting started and even most use, but everytime you restart the
|
||||
hub, all user connections also get restarted. But it's also simple to
|
||||
hub, all user connections also get restarted. But it's also simple to
|
||||
run the proxy as a service separate from the hub, so that you are free
|
||||
to reconfigure the hub while only interrupting users who are currently
|
||||
actively starting the hub.
|
||||
|
||||
The default JupyterHub proxy is
|
||||
[configurable-http-proxy](https://github.com/jupyterhub/configurable-http-proxy),
|
||||
and that page has some docs. If you are using a different proxy, such
|
||||
and that page has some docs. If you are using a different proxy, such
|
||||
as Traefik, these instructions are probably not relevant to you.
|
||||
|
||||
|
||||
## Configuration options
|
||||
|
||||
`c.JupyterHub.cleanup_servers = False` should be set, which tells the
|
||||
@@ -37,24 +35,20 @@ it yourself).
|
||||
token for authenticating communication with the proxy.
|
||||
|
||||
`c.ConfigurableHTTPProxy.api_url = 'http://localhost:8001'` should be
|
||||
set to the URL which the hub uses to connect *to the proxy's API*.
|
||||
|
||||
set to the URL which the hub uses to connect _to the proxy's API_.
|
||||
|
||||
## Proxy configuration
|
||||
|
||||
You need to configure a service to start the proxy. An example
|
||||
command line for this is `configurable-http-proxy --ip=127.0.0.1
|
||||
--port=8000 --api-ip=127.0.0.1 --api-port=8001
|
||||
--default-target=http://localhost:8081
|
||||
--error-target=http://localhost:8081/hub/error`. (Details for how to
|
||||
You need to configure a service to start the proxy. An example
|
||||
command line for this is `configurable-http-proxy --ip=127.0.0.1 --port=8000 --api-ip=127.0.0.1 --api-port=8001 --default-target=http://localhost:8081 --error-target=http://localhost:8081/hub/error`. (Details for how to
|
||||
do this is out of scope for this tutorial - for example it might be a
|
||||
systemd service on within another docker cotainer). The proxy has no
|
||||
systemd service on within another docker cotainer). The proxy has no
|
||||
configuration files, all configuration is via the command line and
|
||||
environment variables.
|
||||
|
||||
`--api-ip` and `--api-port` (which tells the proxy where to listen) should match the hub's `ConfigurableHTTPProxy.api_url`.
|
||||
|
||||
`--ip`, `-port`, and other options configure the *user* connections to the proxy.
|
||||
`--ip`, `-port`, and other options configure the _user_ connections to the proxy.
|
||||
|
||||
`--default-target` and `--error-target` should point to the hub, and used when users navigate to the proxy originally.
|
||||
|
||||
@@ -63,18 +57,16 @@ match the token given to `c.ConfigurableHTTPProxy.auth_token`.
|
||||
|
||||
You should check the [configurable-http-proxy
|
||||
options](https://github.com/jupyterhub/configurable-http-proxy) to see
|
||||
what other options are needed, for example SSL options. Note that
|
||||
what other options are needed, for example SSL options. Note that
|
||||
these are configured in the hub if the hub is starting the proxy - you
|
||||
need to move the options to here.
|
||||
|
||||
|
||||
## Docker image
|
||||
|
||||
You can use [jupyterhub configurable-http-proxy docker
|
||||
image](https://hub.docker.com/r/jupyterhub/configurable-http-proxy/)
|
||||
to run the proxy.
|
||||
|
||||
|
||||
## See also
|
||||
|
||||
* [jupyterhub configurable-http-proxy](https://github.com/jupyterhub/configurable-http-proxy)
|
||||
- [jupyterhub configurable-http-proxy](https://github.com/jupyterhub/configurable-http-proxy)
|
||||
|
||||
@@ -45,17 +45,14 @@ A Service may have the following properties:
|
||||
- `url: str (default - None)` - The URL where the service is/should be. If a
|
||||
url is specified for where the Service runs its own web server,
|
||||
the service will be added to the proxy at `/services/:name`
|
||||
- `api_token: str (default - None)` - For Externally-Managed Services you need to specify
|
||||
- `api_token: str (default - None)` - For Externally-Managed Services you need to specify
|
||||
an API token to perform API requests to the Hub
|
||||
|
||||
If a service is also to be managed by the Hub, it has a few extra options:
|
||||
|
||||
- `command: (str/Popen list)` - Command for JupyterHub to spawn the service.
|
||||
- Only use this if the service should be a subprocess.
|
||||
- If command is not specified, the Service is assumed to be managed
|
||||
externally.
|
||||
- If a command is specified for launching the Service, the Service will
|
||||
be started and managed by the Hub.
|
||||
- `command: (str/Popen list)` - Command for JupyterHub to spawn the service. - Only use this if the service should be a subprocess. - If command is not specified, the Service is assumed to be managed
|
||||
externally. - If a command is specified for launching the Service, the Service will
|
||||
be started and managed by the Hub.
|
||||
- `environment: dict` - additional environment variables for the Service.
|
||||
- `user: str` - the name of a system user to manage the Service. If
|
||||
unspecified, run as the same user as the Hub.
|
||||
@@ -103,9 +100,9 @@ parameters, which describe the environment needed to start the Service process:
|
||||
|
||||
- `environment: dict` - additional environment variables for the Service.
|
||||
- `user: str` - name of the user to run the server if different from the Hub.
|
||||
Requires Hub to be root.
|
||||
Requires Hub to be root.
|
||||
- `cwd: path` directory in which to run the Service, if different from the
|
||||
Hub directory.
|
||||
Hub directory.
|
||||
|
||||
The Hub will pass the following environment variables to launch the Service:
|
||||
|
||||
@@ -199,16 +196,16 @@ can be used by services. You may go beyond this reference implementation and
|
||||
create custom hub-authenticating clients and services. We describe the process
|
||||
below.
|
||||
|
||||
The reference, or base, implementation is the [`HubAuth`][HubAuth] class,
|
||||
The reference, or base, implementation is the [`HubAuth`][hubauth] class,
|
||||
which implements the requests to the Hub.
|
||||
|
||||
To use HubAuth, you must set the `.api_token`, either programmatically when constructing the class,
|
||||
or via the `JUPYTERHUB_API_TOKEN` environment variable.
|
||||
|
||||
Most of the logic for authentication implementation is found in the
|
||||
[`HubAuth.user_for_cookie`][HubAuth.user_for_cookie]
|
||||
and in the
|
||||
[`HubAuth.user_for_token`][HubAuth.user_for_token]
|
||||
Most of the logic for authentication implementation is found in the
|
||||
[`HubAuth.user_for_cookie`][hubauth.user_for_cookie]
|
||||
and in the
|
||||
[`HubAuth.user_for_token`][hubauth.user_for_token]
|
||||
methods, which makes a request of the Hub, and returns:
|
||||
|
||||
- None, if no user could be identified, or
|
||||
@@ -285,11 +282,10 @@ def whoami(user):
|
||||
)
|
||||
```
|
||||
|
||||
|
||||
### Authenticating tornado services with JupyterHub
|
||||
|
||||
Since most Jupyter services are written with tornado,
|
||||
we include a mixin class, [`HubAuthenticated`][HubAuthenticated],
|
||||
we include a mixin class, [`HubAuthenticated`][hubauthenticated],
|
||||
for quickly authenticating your own tornado services with JupyterHub.
|
||||
|
||||
Tornado's `@web.authenticated` method calls a Handler's `.get_current_user`
|
||||
@@ -310,7 +306,6 @@ class MyHandler(HubAuthenticated, web.RequestHandler):
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
The HubAuth will automatically load the desired configuration from the Service
|
||||
environment variables.
|
||||
|
||||
@@ -320,44 +315,42 @@ username and user group list, respectively. If a user matches neither the user
|
||||
list nor the group list, they will not be allowed access. If both are left
|
||||
undefined, then any user will be allowed.
|
||||
|
||||
|
||||
### Implementing your own Authentication with JupyterHub
|
||||
|
||||
If you don't want to use the reference implementation
|
||||
(e.g. you find the implementation a poor fit for your Flask app),
|
||||
you can implement authentication via the Hub yourself.
|
||||
We recommend looking at the [`HubAuth`][HubAuth] class implementation for reference,
|
||||
We recommend looking at the [`HubAuth`][hubauth] class implementation for reference,
|
||||
and taking note of the following process:
|
||||
|
||||
1. retrieve the cookie `jupyterhub-services` from the request.
|
||||
2. Make an API request `GET /hub/api/authorizations/cookie/jupyterhub-services/cookie-value`,
|
||||
where cookie-value is the url-encoded value of the `jupyterhub-services` cookie.
|
||||
This request must be authenticated with a Hub API token in the `Authorization` header,
|
||||
for example using the `api_token` from your [external service's configuration](#externally-managed-services).
|
||||
where cookie-value is the url-encoded value of the `jupyterhub-services` cookie.
|
||||
This request must be authenticated with a Hub API token in the `Authorization` header,
|
||||
for example using the `api_token` from your [external service's configuration](#externally-managed-services).
|
||||
|
||||
For example, with [requests][]:
|
||||
For example, with [requests][]:
|
||||
|
||||
```python
|
||||
r = requests.get(
|
||||
'/'.join(["http://127.0.0.1:8081/hub/api",
|
||||
"authorizations/cookie/jupyterhub-services",
|
||||
quote(encrypted_cookie, safe=''),
|
||||
]),
|
||||
headers = {
|
||||
'Authorization' : 'token %s' % api_token,
|
||||
},
|
||||
)
|
||||
r.raise_for_status()
|
||||
user = r.json()
|
||||
```
|
||||
```python
|
||||
r = requests.get(
|
||||
'/'.join(["http://127.0.0.1:8081/hub/api",
|
||||
"authorizations/cookie/jupyterhub-services",
|
||||
quote(encrypted_cookie, safe=''),
|
||||
]),
|
||||
headers = {
|
||||
'Authorization' : 'token %s' % api_token,
|
||||
},
|
||||
)
|
||||
r.raise_for_status()
|
||||
user = r.json()
|
||||
```
|
||||
|
||||
3. On success, the reply will be a JSON model describing the user:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "inara",
|
||||
"groups": ["serenity", "guild"],
|
||||
|
||||
"groups": ["serenity", "guild"]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -367,12 +360,11 @@ and an example of its configuration is found [here](https://github.com/jupyter/n
|
||||
nbviewer can also be run as a Hub-Managed Service as described [nbviewer README][nbviewer example]
|
||||
section on securing the notebook viewer.
|
||||
|
||||
|
||||
[requests]: http://docs.python-requests.org/en/master/
|
||||
[services_auth]: ../api/services.auth.html
|
||||
[HubAuth]: ../api/services.auth.html#jupyterhub.services.auth.HubAuth
|
||||
[HubAuth.user_for_cookie]: ../api/services.auth.html#jupyterhub.services.auth.HubAuth.user_for_cookie
|
||||
[HubAuth.user_for_token]: ../api/services.auth.html#jupyterhub.services.auth.HubAuth.user_for_token
|
||||
[HubAuthenticated]: ../api/services.auth.html#jupyterhub.services.auth.HubAuthenticated
|
||||
[hubauth]: ../api/services.auth.html#jupyterhub.services.auth.HubAuth
|
||||
[hubauth.user_for_cookie]: ../api/services.auth.html#jupyterhub.services.auth.HubAuth.user_for_cookie
|
||||
[hubauth.user_for_token]: ../api/services.auth.html#jupyterhub.services.auth.HubAuth.user_for_token
|
||||
[hubauthenticated]: ../api/services.auth.html#jupyterhub.services.auth.HubAuthenticated
|
||||
[nbviewer example]: https://github.com/jupyter/nbviewer#securing-the-notebook-viewer
|
||||
[jupyterhub_idle_culler]: https://github.com/jupyterhub/jupyterhub-idle-culler
|
||||
|
||||
@@ -8,18 +8,17 @@ and a custom Spawner needs to be able to take three actions:
|
||||
- poll whether the process is still running
|
||||
- stop the process
|
||||
|
||||
|
||||
## Examples
|
||||
|
||||
Custom Spawners for JupyterHub can be found on the [JupyterHub wiki](https://github.com/jupyterhub/jupyterhub/wiki/Spawners).
|
||||
Some examples include:
|
||||
|
||||
- [DockerSpawner](https://github.com/jupyterhub/dockerspawner) for spawning user servers in Docker containers
|
||||
* `dockerspawner.DockerSpawner` for spawning identical Docker containers for
|
||||
- `dockerspawner.DockerSpawner` for spawning identical Docker containers for
|
||||
each users
|
||||
* `dockerspawner.SystemUserSpawner` for spawning Docker containers with an
|
||||
- `dockerspawner.SystemUserSpawner` for spawning Docker containers with an
|
||||
environment and home directory for each users
|
||||
* both `DockerSpawner` and `SystemUserSpawner` also work with Docker Swarm for
|
||||
- both `DockerSpawner` and `SystemUserSpawner` also work with Docker Swarm for
|
||||
launching containers on remote machines
|
||||
- [SudoSpawner](https://github.com/jupyterhub/sudospawner) enables JupyterHub to
|
||||
run without being root, by spawning an intermediate process via `sudo`
|
||||
@@ -30,7 +29,6 @@ Some examples include:
|
||||
- [SSHSpawner](https://github.com/NERSC/sshspawner) to spawn notebooks
|
||||
on a remote server using SSH
|
||||
|
||||
|
||||
## Spawner control methods
|
||||
|
||||
### Spawner.start
|
||||
@@ -41,7 +39,7 @@ an object encapsulating the user's name, authentication, and server info.
|
||||
|
||||
The return value of `Spawner.start` should be the (ip, port) of the running server.
|
||||
|
||||
**NOTE:** When writing coroutines, *never* `yield` in between a database change and a commit.
|
||||
**NOTE:** When writing coroutines, _never_ `yield` in between a database change and a commit.
|
||||
|
||||
Most `Spawner.start` functions will look similar to this example:
|
||||
|
||||
@@ -80,7 +78,6 @@ to check if the local process is still running. On Windows, it uses `psutil.pid_
|
||||
|
||||
`Spawner.stop` should stop the process. It must be a tornado coroutine, which should return when the process has finished exiting.
|
||||
|
||||
|
||||
## Spawner state
|
||||
|
||||
JupyterHub should be able to stop and restart without tearing down
|
||||
@@ -112,7 +109,6 @@ def clear_state(self):
|
||||
self.pid = 0
|
||||
```
|
||||
|
||||
|
||||
## Spawner options form
|
||||
|
||||
(new in 0.4)
|
||||
@@ -170,8 +166,7 @@ which would return:
|
||||
|
||||
When `Spawner.start` is called, this dictionary is accessible as `self.user_options`.
|
||||
|
||||
|
||||
[Spawner]: https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/spawner.py
|
||||
[spawner]: https://github.com/jupyterhub/jupyterhub/blob/master/jupyterhub/spawner.py
|
||||
|
||||
## Writing a custom spawner
|
||||
|
||||
@@ -212,7 +207,6 @@ Additionally, configurable attributes for your spawner will
|
||||
appear in jupyterhub help output and auto-generated configuration files
|
||||
via `jupyterhub --generate-config`.
|
||||
|
||||
|
||||
## Spawners, resource limits, and guarantees (Optional)
|
||||
|
||||
Some spawners of the single-user notebook servers allow setting limits or
|
||||
@@ -224,10 +218,9 @@ support for them**. For example, LocalProcessSpawner, the default
|
||||
spawner, does not support limits and guarantees. One of the spawners
|
||||
that supports limits and guarantees is the `systemdspawner`.
|
||||
|
||||
|
||||
### Memory Limits & Guarantees
|
||||
|
||||
`c.Spawner.mem_limit`: A **limit** specifies the *maximum amount of memory*
|
||||
`c.Spawner.mem_limit`: A **limit** specifies the _maximum amount of memory_
|
||||
that may be allocated, though there is no promise that the maximum amount will
|
||||
be available. In supported spawners, you can set `c.Spawner.mem_limit` to
|
||||
limit the total amount of memory that a single-user notebook server can
|
||||
@@ -235,8 +228,8 @@ allocate. Attempting to use more memory than this limit will cause errors. The
|
||||
single-user notebook server can discover its own memory limit by looking at
|
||||
the environment variable `MEM_LIMIT`, which is specified in absolute bytes.
|
||||
|
||||
`c.Spawner.mem_guarantee`: Sometimes, a **guarantee** of a *minimum amount of
|
||||
memory* is desirable. In this case, you can set `c.Spawner.mem_guarantee` to
|
||||
`c.Spawner.mem_guarantee`: Sometimes, a **guarantee** of a _minimum amount of
|
||||
memory_ is desirable. In this case, you can set `c.Spawner.mem_guarantee` to
|
||||
to provide a guarantee that at minimum this much memory will always be
|
||||
available for the single-user notebook server to use. The environment variable
|
||||
`MEM_GUARANTEE` will also be set in the single-user notebook server.
|
||||
@@ -271,7 +264,7 @@ utilize these certs, there are two methods of interest on the base `Spawner`
|
||||
class: `.create_certs` and `.move_certs`.
|
||||
|
||||
The first method, `.create_certs` will sign a key-cert pair using an internally
|
||||
trusted authority for notebooks. During this process, `.create_certs` can
|
||||
trusted authority for notebooks. During this process, `.create_certs` can
|
||||
apply `ip` and `dns` name information to the cert via an `alt_names` `kwarg`.
|
||||
This is used for certificate authentication (verification). Without proper
|
||||
verification, the `Notebook` will be unable to communicate with the `Hub` and
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Working with templates and UI
|
||||
|
||||
The pages of the JupyterHub application are generated from
|
||||
[Jinja](http://jinja.pocoo.org/) templates. These allow the header, for
|
||||
example, to be defined once and incorporated into all pages. By providing
|
||||
[Jinja](http://jinja.pocoo.org/) templates. These allow the header, for
|
||||
example, to be defined once and incorporated into all pages. By providing
|
||||
your own templates, you can have complete control over JupyterHub's
|
||||
appearance.
|
||||
|
||||
@@ -20,7 +20,7 @@ or as few templates as you desire.
|
||||
|
||||
Jinja provides a mechanism to [extend templates](http://jinja.pocoo.org/docs/2.10/templates/#template-inheritance).
|
||||
A base template can define a `block`, and child templates can replace or
|
||||
supplement the material in the block. The
|
||||
supplement the material in the block. The
|
||||
[JupyterHub templates](https://github.com/jupyterhub/jupyterhub/tree/master/share/jupyterhub/templates)
|
||||
make extensive use of blocks, which allows you to customize parts of the
|
||||
interface easily.
|
||||
@@ -32,8 +32,8 @@ In general, a child template can extend a base template, `page.html`, by beginni
|
||||
```
|
||||
|
||||
This works, unless you are trying to extend the default template for the same
|
||||
file name. Starting in version 0.9, you may refer to the base file with a
|
||||
`templates/` prefix. Thus, if you are writing a custom `page.html`, start the
|
||||
file name. Starting in version 0.9, you may refer to the base file with a
|
||||
`templates/` prefix. Thus, if you are writing a custom `page.html`, start the
|
||||
file with this block:
|
||||
|
||||
```html
|
||||
@@ -41,7 +41,7 @@ file with this block:
|
||||
```
|
||||
|
||||
By defining `block`s with same name as in the base template, child templates
|
||||
can replace those sections with custom content. The content from the base
|
||||
can replace those sections with custom content. The content from the base
|
||||
template can be included with the `{{ super() }}` directive.
|
||||
|
||||
### Example
|
||||
@@ -52,10 +52,7 @@ text about the server starting up, place this content in a file named
|
||||
`JupyterHub.template_paths` configuration option.
|
||||
|
||||
```html
|
||||
{% extends "templates/spawn_pending.html" %}
|
||||
|
||||
{% block message %}
|
||||
{{ super() }}
|
||||
{% extends "templates/spawn_pending.html" %} {% block message %} {{ super() }}
|
||||
<p>Patience is a virtue.</p>
|
||||
{% endblock %}
|
||||
```
|
||||
@@ -69,9 +66,8 @@ To add announcements to be displayed on a page, you have two options:
|
||||
|
||||
### Announcement Configuration Variables
|
||||
|
||||
If you set the configuration variable `JupyterHub.template_vars =
|
||||
{'announcement': 'some_text'}`, the given `some_text` will be placed on
|
||||
the top of all pages. The more specific variables
|
||||
If you set the configuration variable `JupyterHub.template_vars = {'announcement': 'some_text'}`, the given `some_text` will be placed on
|
||||
the top of all pages. The more specific variables
|
||||
`announcement_login`, `announcement_spawn`, `announcement_home`, and
|
||||
`announcement_logout` are more specific and only show on their
|
||||
respective pages (overriding the global `announcement` variable).
|
||||
@@ -79,13 +75,12 @@ Note that changing these variables require a restart, unlike direct
|
||||
template extension.
|
||||
|
||||
You can get the same effect by extending templates, which allows you
|
||||
to update the messages without restarting. Set
|
||||
to update the messages without restarting. Set
|
||||
`c.JupyterHub.template_paths` as mentioned above, and then create a
|
||||
template (for example, `login.html`) with:
|
||||
|
||||
```html
|
||||
{% extends "templates/login.html" %}
|
||||
{% set announcement = 'some message' %}
|
||||
{% extends "templates/login.html" %} {% set announcement = 'some message' %}
|
||||
```
|
||||
|
||||
Extending `page.html` puts the message on all pages, but note that
|
||||
|
||||
@@ -11,8 +11,6 @@ All authenticated handlers redirect to `/hub/login` to login users
|
||||
prior to being redirected back to the originating page.
|
||||
The returned request should preserve all query parameters.
|
||||
|
||||
|
||||
|
||||
## `/`
|
||||
|
||||
The top-level request is always a simple redirect to `/hub/`,
|
||||
@@ -61,7 +59,7 @@ for starting and stopping the user's server.
|
||||
If named servers are enabled, there will be some additional
|
||||
tools for management of named servers.
|
||||
|
||||
*Version added: 1.0* named server UI is new in 1.0.
|
||||
_Version added: 1.0_ named server UI is new in 1.0.
|
||||
|
||||
## `/hub/login`
|
||||
|
||||
@@ -111,7 +109,7 @@ not the Hub.
|
||||
The username is the first part and, if using named servers,
|
||||
the server name is the second part.
|
||||
|
||||
If the user's server is *not* running, this will be redirected to `/hub/user/:username/...`
|
||||
If the user's server is _not_ running, this will be redirected to `/hub/user/:username/...`
|
||||
|
||||
## `/hub/user/:username[/:servername]`
|
||||
|
||||
@@ -123,8 +121,8 @@ Handling this URL is the most complicated condition in JupyterHub,
|
||||
because there can be many states:
|
||||
|
||||
1. server is not active
|
||||
a. user matches
|
||||
b. user doesn't match
|
||||
a. user matches
|
||||
b. user doesn't match
|
||||
2. server is ready
|
||||
3. server is pending, but not ready
|
||||
|
||||
@@ -146,7 +144,7 @@ without additional user action (i.e. clicking the link on the page)
|
||||
|
||||
|
||||
|
||||
*Version changed: 1.0*
|
||||
_Version changed: 1.0_
|
||||
|
||||
Prior to 1.0, this URL itself was responsible for spawning servers,
|
||||
and served the progress page if it was pending,
|
||||
@@ -165,7 +163,7 @@ indicating how to spawn the server.
|
||||
This is meant to help applications such as JupyterLab
|
||||
that are connected to a server that has stopped.
|
||||
|
||||
*Version changed: 1.0*
|
||||
_Version changed: 1.0_
|
||||
|
||||
JupyterHub 0.9 failed these API requests with status 404,
|
||||
but 1.0 uses 503.
|
||||
@@ -207,12 +205,12 @@ and a POST request will trigger the actual spawn and redirect.
|
||||
|
||||
|
||||
|
||||
*Version added: 1.0*
|
||||
_Version added: 1.0_
|
||||
|
||||
1.0 adds the ability to specify username and servername.
|
||||
Prior to 1.0, only `/hub/spawn` was recognized for the default server.
|
||||
|
||||
*Version changed: 1.0*
|
||||
_Version changed: 1.0_
|
||||
|
||||
Prior to 1.0, this page redirected back to `/hub/user/:username`,
|
||||
which was responsible for triggering spawn and rendering progress, etc.
|
||||
@@ -221,7 +219,7 @@ which was responsible for triggering spawn and rendering progress, etc.
|
||||
|
||||
|
||||
|
||||
*Version added: 1.0* this URL is new in JupyterHub 1.0.
|
||||
_Version added: 1.0_ this URL is new in JupyterHub 1.0.
|
||||
|
||||
This page renders the progress view for the given spawn request.
|
||||
Once the server is ready,
|
||||
|
||||
@@ -12,17 +12,17 @@ works.
|
||||
|
||||
## Semi-trusted and untrusted users
|
||||
|
||||
JupyterHub is designed to be a *simple multi-user server for modestly sized
|
||||
groups* of **semi-trusted** users. While the design reflects serving semi-trusted
|
||||
JupyterHub is designed to be a _simple multi-user server for modestly sized
|
||||
groups_ of **semi-trusted** users. While the design reflects serving semi-trusted
|
||||
users, JupyterHub is not necessarily unsuitable for serving **untrusted** users.
|
||||
|
||||
Using JupyterHub with **untrusted** users does mean more work by the
|
||||
administrator. Much care is required to secure a Hub, with extra caution on
|
||||
protecting users from each other as the Hub is serving untrusted users.
|
||||
|
||||
One aspect of JupyterHub's *design simplicity* for **semi-trusted** users is that
|
||||
the Hub and single-user servers are placed in a *single domain*, behind a
|
||||
[*proxy*][configurable-http-proxy]. If the Hub is serving untrusted
|
||||
One aspect of JupyterHub's _design simplicity_ for **semi-trusted** users is that
|
||||
the Hub and single-user servers are placed in a _single domain_, behind a
|
||||
[_proxy_][configurable-http-proxy]. If the Hub is serving untrusted
|
||||
users, many of the web's cross-site protections are not applied between
|
||||
single-user servers and the Hub, or between single-user servers and each
|
||||
other, since browsers see the whole thing (proxy, Hub, and single user
|
||||
@@ -40,7 +40,7 @@ server.
|
||||
To protect all users from each other, JupyterHub administrators must
|
||||
ensure that:
|
||||
|
||||
* A user **does not have permission** to modify their single-user notebook server,
|
||||
- A user **does not have permission** to modify their single-user notebook server,
|
||||
including:
|
||||
- A user **may not** install new packages in the Python environment that runs
|
||||
their single-user server.
|
||||
@@ -49,11 +49,11 @@ ensure that:
|
||||
directory that precedes the directory containing `jupyterhub-singleuser`.
|
||||
- A user may not modify environment variables (e.g. PATH, PYTHONPATH) for
|
||||
their single-user server.
|
||||
* A user **may not** modify the configuration of the notebook server
|
||||
- A user **may not** modify the configuration of the notebook server
|
||||
(the `~/.jupyter` or `JUPYTER_CONFIG_DIR` directory).
|
||||
|
||||
If any additional services are run on the same domain as the Hub, the services
|
||||
**must never** display user-authored HTML that is neither *sanitized* nor *sandboxed*
|
||||
**must never** display user-authored HTML that is neither _sanitized_ nor _sandboxed_
|
||||
(e.g. IFramed) to any user that lacks authentication as the author of a file.
|
||||
|
||||
## Mitigate security issues
|
||||
@@ -85,7 +85,7 @@ admin must enforce.
|
||||
### Prevent spawners from evaluating shell configuration files
|
||||
|
||||
For most Spawners, `PATH` is not something users can influence, but care should
|
||||
be taken to ensure that the Spawner does *not* evaluate shell configuration
|
||||
be taken to ensure that the Spawner does _not_ evaluate shell configuration
|
||||
files prior to launching the server.
|
||||
|
||||
### Isolate packages using virtualenv
|
||||
@@ -125,7 +125,6 @@ versions up to date.
|
||||
A handy website for testing your deployment is
|
||||
[Qualsys' SSL analyzer tool](https://www.ssllabs.com/ssltest/analyze.html).
|
||||
|
||||
|
||||
[configurable-http-proxy]: https://github.com/jupyterhub/configurable-http-proxy
|
||||
|
||||
## Vulnerability reporting
|
||||
|
||||
Reference in New Issue
Block a user