sync with main

.github/workflows/release.yml

@@ -149,7 +149,7 @@ jobs:
           branchRegex: ^\w[\w-.]*$
 
       - name: Build and push jupyterhub
-        uses: docker/build-push-action@37abcedcc1da61a57767b7588cb9d03eb57e28b3
+        uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
         with:
           context: .
           platforms: linux/amd64,linux/arm64
@@ -170,7 +170,7 @@ jobs:
           branchRegex: ^\w[\w-.]*$
 
       - name: Build and push jupyterhub-onbuild
-        uses: docker/build-push-action@37abcedcc1da61a57767b7588cb9d03eb57e28b3
+        uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
         with:
           build-args: |
             BASE_IMAGE=${{ fromJson(steps.jupyterhubtags.outputs.tags)[0] }}
@@ -191,7 +191,7 @@ jobs:
           branchRegex: ^\w[\w-.]*$
 
       - name: Build and push jupyterhub-demo
-        uses: docker/build-push-action@37abcedcc1da61a57767b7588cb9d03eb57e28b3
+        uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
         with:
           build-args: |
             BASE_IMAGE=${{ fromJson(steps.onbuildtags.outputs.tags)[0] }}
@@ -215,7 +215,7 @@ jobs:
           branchRegex: ^\w[\w-.]*$
 
       - name: Build and push jupyterhub/singleuser
-        uses: docker/build-push-action@37abcedcc1da61a57767b7588cb9d03eb57e28b3
+        uses: docker/build-push-action@3b5e8027fcad23fda98b2e3ac259d8d67585f671
         with:
           build-args: |
             JUPYTERHUB_VERSION=${{ github.ref_type == 'tag' && github.ref_name || format('git:{0}', github.sha) }}

.pre-commit-config.yaml

@@ -24,7 +24,7 @@ repos:
 
   # Autoformat: Python code
   - repo: https://github.com/PyCQA/autoflake
-    rev: v2.0.0
+    rev: v2.0.1
     hooks:
       - id: autoflake
         # args ref: https://github.com/PyCQA/autoflake#advanced-usage
@@ -39,7 +39,7 @@ repos:
 
   # Autoformat: Python code
   - repo: https://github.com/psf/black
-    rev: 22.12.0
+    rev: 23.1.0
     hooks:
       - id: black
 

docs/source/changelog.md

@@ -1,3 +1,5 @@
+(changelog)=
+
 # Changelog
 
 For detailed changes from the prior release, click on the version number, and
@@ -205,7 +207,7 @@ More info in {ref}`available-scopes-target`.
 
 - The admin UI can now show more detailed info about users and their servers in a drop-down details table:
 
-  ![Details view in admin UI](./images/dropdown-details-3.0.png)
+  ![Details view in admin UI](/images/dropdown-details-3.0.png)
 
 - Several bugfixes and improvements in the new admin UI.
 - Direct access to the Hub's database is deprecated.
@@ -1353,7 +1355,7 @@ whether it was through discussion, testing, documentation, or development.
 - There is now full UI support for managing named servers.
   With named servers, each jupyterhub user may have access to more than one named server. For example, a professor may access a server named `research` and another named `teaching`.
 
-  ![named servers on the home page](./images/named-servers-home.png)
+  ![named servers on the home page](/images/named-servers-home.png)
 
 - Authenticators can now expire and refresh authentication data by implementing
   `Authenticator.refresh_user(user)`.

docs/source/contributing/security.md

@@ -1,7 +1,7 @@
 # Reporting security issues in Jupyter or JupyterHub
 
 If you find a security vulnerability in Jupyter or JupyterHub,
-whether it is a failure of the security model described in {doc}`../reference/websecurity`
+whether it is a failure of the security model described in [Security Overview](web-security)
 or a failure in implementation,
 please report it to <mailto:security@ipython.org>.
 

docs/source/contributing/setup.md

@@ -103,7 +103,7 @@ a more detailed discussion.
    The default database engine is `sqlite` so if you are just trying
    to get up and running quickly for local development that should be
    available via [Python](https://docs.python.org/3.5/library/sqlite3.html).
-   See {doc}`/reference/database` for details on other supported databases.
+   See [The Hub's Database](hub-database) for details on other supported databases.
 
 6. You are now ready to start JupyterHub!
 

docs/source/admin/capacity-planning.md → docs/source/explanation/admin/capacity-planning.md

@@ -40,7 +40,7 @@ The rest is going to be up to your users.
 Per-user overhead from JupyterHub is typically negligible
 up to at least a few hundred concurrent active users.
 
-```{figure} ../images/mybinder-hub-components-cpu-memory.png
+```{figure} /images/mybinder-hub-components-cpu-memory.png
 JupyterHub component resource usage for mybinder.org.
 ```
 
@@ -200,7 +200,7 @@ The limit here is actually Kubernetes' pods per node, not memory _or_ CPU.
 This is likely a extreme case, as many Binder users come from clicking links on webpages
 without any actual intention of running code.
 
-```{figure} ../images/mybinder-load5.png
+```{figure} /images/mybinder-load5.png
 mybinder.org node CPU usage is low with 50-150 users sharing just 8 cores
 ```
 
@@ -277,7 +277,7 @@ showing >90% of users using less than 10% CPU and 200MB,
 but a few outliers near the limit of 1 CPU and 2GB of RAM.
 This is the kind of information you can use to tune your requests and limits.
 
-![Snapshot from JupyterHub's Grafana dashboards on mybinder.org](../images/mybinder-user-resources.png)
+![Snapshot from JupyterHub's Grafana dashboards on mybinder.org](/images/mybinder-user-resources.png)
 
 [prometheus]: https://prometheus.io
 [grafana]: https://grafana.com

docs/source/reference/database.md → docs/source/explanation/admin/database.md

@@ -1,3 +1,5 @@
+(hub-database)=
+
 # The Hub's Database
 
 JupyterHub uses a database to store information about users, services, and other data needed for operating the Hub.
@@ -80,7 +82,7 @@ Additionally, there is usually _very_ little load on the database itself.
 By far the most taxing activity on the database is the 'list all users' endpoint, primarily used by the [idle-culling service](https://github.com/jupyterhub/jupyterhub-idle-culler).
 Database-based optimizations have been added to make even these operations feasible for large numbers of users:
 
-1. State filtering on [GET /users](./rest-api.md) with `?state=active`,
+1. State filtering on [GET /users](jupyterhub-rest-API) with `?state=active`,
    which limits the number of results in the query to only the relevant subset (added in JupyterHub 1.3), rather than all users.
 2. [Pagination](api-pagination) of all list endpoints, allowing the request of a large number of resources to be more fairly balanced with other Hub activities across multiple requests (added in 2.0).
 

docs/source/reference/oauth.md → docs/source/explanation/admin/oauth.md

@@ -255,7 +255,7 @@ To authenticate this request, the single token stored in the encrypted cookie is
 
 If the user model matches who should be allowed (e.g. Danez),
 then the request is allowed.
-See {doc}`../rbac/scopes` for how JupyterHub uses scopes to determine authorized access to servers and services.
+See [Scopes in JupyterHub](jupyterhub-scopes) for how JupyterHub uses scopes to determine authorized access to servers and services.
 
 _the end_
 

docs/source/reference/websecurity.md → docs/source/explanation/admin/websecurity.md

@@ -1,3 +1,5 @@
+(web-security)=
+
 # Security Overview
 
 The **Security Overview** section helps you learn about:

docs/source/explanation/index.md

@@ -1,8 +1,30 @@
 # Explanation
 
-The explanation guides are written to provide big-picture explanations of how JupyterHub works. They are meant to build your understanding of particular topics.
+_Explanation_ documentation provide big-picture descriptions of how JupyterHub works. This section is meant to build your understanding of particular topics.
+
+## Administration
+
+This section provides information relevant to running your own JupyterHub over time.
+
+```{toctree}
+:maxdepth: 1
+
+admin/capacity-planning
+admin/database
+admin/websecurity
+admin/oauth
+```
+
+## JupyterHub RBAC
+
+This section covers how Role Based Access Control (RBAC) is implemented in JupyterHub to control access to Jupyterhub's API resources.
+
+<!---
+The JupyterHub RBAC source files are contained in the source/rbac folder
+--->
 
 ```{toctree}
 :maxdepth: 2
 
+../rbac/index
 ```

docs/source/index.md

@@ -55,8 +55,8 @@ Documentation sections (reorganization in-progress)
 
 tutorial/index.md
 howto/index.md
-explanation/index.md
 reference/index.md
+explanation/index.md
 faq/index.md
 ```
 
@@ -81,14 +81,6 @@ Today, you can find two main use cases:
 _It is important to evaluate these distributions before you can continue with the
 configuration of JupyterHub_.
 
-### Getting Started
-
-```{toctree}
-:maxdepth: 2
-
-getting-started/index
-```
-
 ### Technical Reference
 
 ```{toctree}
@@ -97,14 +89,6 @@ getting-started/index
 reference/index
 ```
 
-### Administrators guide
-
-```{toctree}
-:maxdepth: 2
-
-index-admin
-```
-
 ### API Reference
 
 ```{toctree}
@@ -113,14 +97,6 @@ index-admin
 api/index
 ```
 
-### RBAC Reference
-
-```{toctree}
-:maxdepth: 2
-
-rbac/index
-```
-
 ### Contributing
 
 We welcome you to contribute to JupyterHub in ways that are most exciting

docs/source/rbac/index.md

@@ -1,4 +1,9 @@
-(RBAC)=
+<!---
+RBAC docs are part of the Explanation section of the JupyterHub documentation.
+As a result, this index file is referenced in the toctree within the explanation/index.md file.
+--->
+
+(rbac)=
 
 # JupyterHub RBAC
 

docs/source/rbac/scopes.md

@@ -1,8 +1,10 @@
+(jupyterhub-scopes)=
+
 # Scopes in JupyterHub
 
 A scope has a syntax-based design that reveals which resources it provides access to. Resources are objects with a type, associated data, relationships to other resources, and a set of methods that operate on them (see [RESTful API](https://restful-api-design.readthedocs.io/en/latest/resources.html) documentation for more information).
 
-`<resource>` in the RBAC scope design refers to the resource name in the [JupyterHub's API](../reference/rest-api.md) endpoints in most cases. For instance, `<resource>` equal to `users` corresponds to JupyterHub's API endpoints beginning with _/users_.
+`<resource>` in the RBAC scope design refers to the resource name in the [JupyterHub's API](jupyterhub-rest-API) endpoints in most cases. For instance, `<resource>` equal to `users` corresponds to JupyterHub's API endpoints beginning with _/users_.
 
 (scope-conventions-target)=
 
@@ -298,6 +300,6 @@ Custom scope _filters_ are NOT supported.
 
 ### Scopes and APIs
 
-The scopes are also listed in the [](../reference/rest-api.md) documentation. Each API endpoint has a list of scopes which can be used to access the API; if no scopes are listed, the API is not authenticated and can be accessed without any permissions (i.e., no scopes).
+The scopes are also listed in the [](jupyterhub-rest-API) documentation. Each API endpoint has a list of scopes which can be used to access the API; if no scopes are listed, the API is not authenticated and can be accessed without any permissions (i.e., no scopes).
 
 Listed scopes by each API endpoint reflect the "lowest" permissions required to gain any access to the corresponding API. For example, posting user's activity (_POST /users/:name/activity_) needs `users:activity` scope. If scope `users` is passed during the request, the access will be granted as the required scope is a subscope of the `users` scope. If, on the other hand, `read:users:activity` scope is passed, the access will be denied.

docs/source/rbac/tech-implementation.md

@@ -65,7 +65,7 @@ If the token's scopes are a subset of the token owner's scopes, the token is iss
 
 {ref}`Figure 1 <token-request-chart>` below illustrates the steps involved. The orange rectangles highlight where in the process the roles and scopes are resolved.
 
-```{figure} ../images/rbac-token-request-chart.png
+```{figure} /images/rbac-token-request-chart.png
 :align: center
 :name: token-request-chart
 
@@ -91,7 +91,7 @@ The passed scopes are compared to the scopes required to access the API as follo
 
 {ref}`Figure 2 <api-request-chart>` illustrates this process highlighting the steps where the role and scope resolutions as well as filtering occur in orange.
 
-```{figure} ../images/rbac-api-request-chart.png
+```{figure} /images/rbac-api-request-chart.png
 :align: center
 :name: api-request-chart
 

docs/source/rbac/upgrade.md

@@ -45,7 +45,7 @@ OAuth token is issued by the Hub to a single-user server when the user logs in.
 
 API token is issued by the Hub to a single-user server when launched and is used to communicate with the Hub's APIs such as posting activity or completing the OAuth flow. This token has no expiry by default.
 
-API tokens can also be issued to users via API ([_/hub/token_](../reference/urls.md) or [_POST /users/:username/tokens_](../reference/rest-api.md)) and services via `jupyterhub_config.py` to perform API requests.
+API tokens can also be issued to users via API ([_/hub/token_](jupyterhub-url) or [_POST /users/:username/tokens_](jupyterhub-rest-API)) and services via `jupyterhub_config.py` to perform API requests.
 
 ### With RBAC
 

docs/source/rbac/use-cases.md

@@ -3,13 +3,13 @@
 To determine which scopes a role should have, one can follow these steps:
 
 1. Determine what actions the role holder should have/have not access to
-2. Match the actions against the [JupyterHub's APIs](../reference/rest-api.md)
+2. Match the actions against the [JupyterHub's APIs](jupyterhub-rest-API)
 3. Check which scopes are required to access the APIs
 4. Combine scopes and subscopes if applicable
 5. Customize the scopes with filters if needed
 6. Define the role with required scopes and assign to users/services/groups/tokens
 
-Below, different use cases are presented on how to use the [RBAC framework](./index.md)
+Below, different use cases are presented on how to use the [RBAC framework](rbac)
 
 ## Service to cull idle servers
 

docs/source/reference/index.md

@@ -1,3 +1,5 @@
+(reference-index)=
+
 # Technical Reference
 
 This section covers more of the details of the JupyterHub architecture, as well as
@@ -8,15 +10,11 @@ what happens under-the-hood when you deploy and configure your JupyterHub.
 
 technical-overview
 urls
-websecurity
 authenticators
 spawners
 services
 rest-api
-server-api
 monitoring
-database
 ../events/index
 config-reference
-oauth
 ```

docs/source/reference/technical-overview.md

@@ -110,7 +110,7 @@ working directory:
   This file needs to persist so that a **Hub** server restart will avoid
   invalidating cookies. Conversely, deleting this file and restarting the server
   effectively invalidates all login cookies. The cookie secret file is discussed
-  in the [Cookie Secret section of the Security Settings document](../getting-started/security-basics.md).
+  in the [Cookie Secret section of the Security Settings document](security-basics).
 
 The location of these files can be specified via configuration settings. It is
 recommended that these files be stored in standard UNIX filesystem locations,

docs/source/reference/urls.md

@@ -1,3 +1,5 @@
+(jupyterhub-url)=
+
 # JupyterHub URL scheme
 
 This document describes how JupyterHub routes requests.