singleuser auth as server extension

[minrk]

This is a development branch, testing JupyterHub singleuser auth as a Jupyter Server extension

Jupyter Server 2.0 introduces two new APIs:

• IdentityProvider for configuring authentication
• Authorizer for configuring authorization (enables granular access, such as read-only)

This PR aims to implement these APIs for JupyterHub, without (almost) any use of monkeypatching or private APIs.
So far, I've got ~everything working in manual tests, aside from disable_user_config. I'm not 100% sure how feasible that's going to be, but hopefully I can manage.

It doesn't remove or change SingleUserNotebookApp. It mostly copies code from there (essentially a fork of the singleuser code), so that the old code can be deprecated and removed at a later time.

Co-developing this with jupyter-server/jupyter_server#825 as a way to validate that everything JupyterHub needs to fit in a server extension is covered.

TODO:

• complete implementation
• test/demonstrate custom Authorizer that isn't the default JupyterHub Authorizer to make sure this is possible
• add extension + server 2.0 to test matrix
• figure out what to do for SingleUserNotebookApp, which is likely to be incompatible with server 2.0, and defaults in jupyterhub.singleuser
• figure out disable_user_config
• default to extension when running with Jupyter Server 2

[minrk]

Finally got this working! (writing before CI is green, but I'm optimistic)

Key changes:

• the only change to the existing monkeypatch-app code is loading the custom page.html from a shared file
• In testing, the StubSingleUserServer which ran a singleuser server in a thread for easier assertions/introspection was too hard to keep working in all possible combinations. So I elected for a simpler, cleaner, more realistic launch of subprocess servers, and an extension to enable inspecting it over the network. This works fine and is a lot simpler.

The rest is just implementing the same behavior via standard server-2.0 public APIs instead of the monkeypatching.

Questions:

• should the extension be the default if jupyter-server 2 is present? I think maybe yes. The only reason not to is Server 2 is out, so this is a change in behavior (I had hoped to finish this PR while 2 was in prerelease, but life got in the way).

[consideRatio]

Amazing work on this @minrk! I think it seems very thoroughly done!

My review notes mostly include details:

• request for additional details in docstrings
• questions about TODO notes
• small refactoring considerations for readability
• questions about things I don't understand

---

I've not reviewed things below line ~260 or so in the extension.py file, a bit into the code that you describe is copied from the mixin - everything else though!

[minrk]

@consideRatio thanks for the thoughtful review! I'll work on addressing the points now.

[minrk]

had to re-sync with main to get the updated black config

[minrk]

@consideRatio thanks for the suggestions! I've added detail where I could in docstrings and comments based on your review. I also updated the extension to be usd by default with Jupyter Server 2, which for JupyterHub 4 I think is the right thing to do.

[consideRatio]

The new changes looks great to me! I really love the docstring additions!!!

There is a timeout failure in the tests to resolve, but from what I could tell this looked good!

[minrk]

Because this has been going for so long, I'm going to do the default-switch in its own PR, rather than tack on another change. I realize changing the default also means changing the test matrix to make sure the cases are still covered.

[minrk]

@consideRatio good catch on the check_hub_version! Adding the call that should have been there is the reason for the hang, because the URL attribute needed to be updated for the extension, since it's on a different object. Should be okay now.

[consideRatio]

Wow amazing work on this!!! Super happy about how this is now an extension of jupyter-server!