User hook for the build endpoint

Proposed change

This issue is related to the idea mentioned in this Discourse topic: https://discourse.jupyter.org/t/binderhub-with-private-gitlab-and-user-scopes/3502

Looking at the code, it seems like there is (at the moment) no hook or option that could be set to tweak the behavior of the /build endpoint, or more generally of the buidler.

The idea is to be able to implement fine-grained access control to BinderHub based on the JupyterHub authenticator used to authenticate users.

The use case is summarized as follows:

• Users authenticate to their BinderHub using their private GitLab instance as the authenticator
• This means that each BinderHub user now corresponds to a GitLab user
• When they enter the repository in the input field, they can only build repositories they have access to
• If they don’t have access, the Could not resolve ref for my-project/repo. Double check your URL. would ideally be shown
• This would happen before triggering a new build
• [Optional] The UI only shows GitLab in the dropdown menu (after configuring repo_providers). This looks like it should be solved by https://github.com/jupyterhub/binderhub/pull/1038 🎉

Alternative options

An alternative option might be to add an extra build handler to the main app, and change the frontend to use that endpoint instead.

However this adds a lot of complexity to the BinderHub admin as it would require maintaining custom Docker images and helm charts with these changes.

Who would use this feature?

Those who want to have a custom BinderHub setup implementing user access based on the user access pattern from the JupyterHub authenticator (GitLab, GitHub).

(Optional): Suggest a solution

Provided that an access token was generated according to: https://binderhub.readthedocs.io/en/latest/zero-to-binderhub/setup-binderhub.html#accessing-private-repositories

For a binderhub user that has read-only access to all repositories.

And the token set as:

config:
  GitLabRepoProvider:
    private_token: "<access token>"

At the moment it’s possible to have control on the launch behavior, by providing the following snippet to the helm chart config:

https://github.com/jupyterhub/binderhub/blob/b6446b12b30f741d9e82b7aec1498ede4776cd79/helm-chart/binderhub/values.yaml#L66-L119

However users can still trigger a build to a repository they do not have access to.

It looks like this could be implemented by providing a custom RepoProvider (in the helm config value, that could derive from an existing one).

But it would require some user specific information to be passed to the RepoProvider to be able to decide whether or not it is possible to resolve the ref for that user, probably somewhere around this line:

https://github.com/jupyterhub/binderhub/blob/72bcb59cf956f53a07f0d4b45f12cc6c1257c6cf/binderhub/builder.py#L251

A custom hook similar to the pre_spawn_hook or user_redirect_hook in JupyterHub could also help.

Or how about having a pre_build_hook, similar to the existing pre_launch_hook?

https://github.com/jupyterhub/binderhub/blob/72bcb59cf956f53a07f0d4b45f12cc6c1257c6cf/binderhub/launcher.py#L67-L78

The pre_build_hook could then perform some API requests to GitHub / GitLab to check if a user has access to a specific repo.

[jtpio]

Just tested and we can indeed retrieve the user auth_state 👍

For example in the pre_launch_hook with:

async def pre_launch_hook(launcher, image, username, server_name, repo_url):
	user = await launcher.get_user_data(username)
	auth_state = user.get('auth_state', None)

With a pre_build_hook, we could probably achieve a similar thing with:

async def pre_build_hook(handler):
    user_model = handler.hub_auth.get_user(handler)
    username = user_model['name']

    # ideally reusing the api_request or get_user_data methods from the launcher 
    resp = await api_request(f'users/{username}', method='GET')
    user = json.loads(resp.body.decode('utf-8'))
    auth_state = user.get('auth_state', None)

[bitnik]

I am for pre_build_hook:

• you could check anything (similar to the check if spec is valid) before the build process starts. so probably the pre_build_hook should be called just before these lines

https://github.com/jupyterhub/binderhub/blob/72bcb59cf956f53a07f0d4b45f12cc6c1257c6cf/binderhub/builder.py#L234-L240

• in hook you could reach user data easily (probably) with user_model = self.hub_auth.get_user(self)