-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow dynamic repository credentials for authenticated Binderhub instances. #1169
base: main
Are you sure you want to change the base?
Allow dynamic repository credentials for authenticated Binderhub instances. #1169
Conversation
Thanks for opening this! I'm not sure passing the handler to the repoprovider is the right implementation, but having a concrete use case is very helpful. Some thoughts:
|
Hi @minrk, Thanks for your reply! Regarding the Handler's Regarding the other points, yes, at least for this use case limiting ourselves to passing the user info to the RepoProvider would be enough. |
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/a-question-about-binderhub-authentication-and-privacy/7758/2 |
Hi! That would be definitely a great feature !
I would propose to fetch the user model once and only when Then, you could just write your configuration as follow: from binderhub.repoproviders import GitLabRepoProvider
from traitlets import default
class AuthGitLabProvider(GitLabRepoProvider):
def __init__(self, *args, user_model, **kwargs):
self.access_token = user_model['auth_state']['access_token']
super().__init__(*args, **kwargs)
@default('git_credentials')
def _default_git_credentials(self):
if self.access_token:
return r'username=oauth2\npassword={token}'.format(token=self.access_token)
return ""
c.BinderHub.repo_providers = {'gl': AuthGitLabProvider} |
@adriendelsalle that looks good to me! |
I would be happy to open a PR on your fork if you add me as a collaborator on it! |
OK I just did, but I'm not sure if it would be valuable (what's the workflow?), maybe opening a PR on the main repo referencing this one would be better? Sorry for the naive question :-) |
Pass user model to RepoProvider
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/private-gitlab-access-for-binderhub/504/9 |
Any chances, that we can get this merged? |
I tested it. Worked perfectly with the update of @adriendelsalle ! |
…b.com/rprimet/binderhub into dynamic_credentials_for_repoproviders
275851b
to
4eca8d2
Compare
Seems that I messed something up while trying to sync with the current master. Yet master...rprimet:dynamic_credentials_for_repoproviders still seems to show the correct diff so I'm puzzled as to why... |
275851b
to
748e13d
Compare
Did you rebased or merged ? only rebase :). |
@adriendelsalle great thanks! |
…b.com/rprimet/binderhub into dynamic_credentials_for_repoproviders
Is there anything else (e.g. tests) to do on this PR? |
When will this be merged and available? I have a use case where users would want to share only with other people authorized on their repo. |
What is the exact status of this PR? Seems to me like @adriendelsalle provided an helpful workaround which answered most if not all the objections raised in @minrk's remark, so it would be nice for the feature to be merged if the solution is good enough. Thanks! |
Hey @minrk, could you please take a look at this again? :) |
This PR is related to issue #1154
Proposed change
Make it possible to fill repo provider / git credentials for a forge (e.g. gitlab instance) dynamically using the currently logged-in user information. This would help set up binderhub instances for use with private repositories for organizations that run a forge (e.g. gitlab instance).
Scope
This change is meant for authenticated Binderhubs (e.g. an instance of BinderHub that is authenticated against a Gitlab instance and whose main purpose is to build repositories hosted in that instance). It does not address building private repositories from an anonymous Binderhub instance (which would probably entail UI changes and/or a complex authentication workflow?).
In that use case, an auth-aware RepoProvider could assume that auth information is available.
Issues
The example RepoProvider (
AuthGitLabProvider
) in issue Build/launch private repositories as the logged-in user (within an authenticated binderhub instance) #1154 makes a blocking http call in the initializer to retrieve auth info -- this should be made asynchronous, but I'm not sure how.It should be possible to fill default traitlets config attributes (e.g.
default_git_credentials
) using dynamic credentials, after retrieving those credentials asynchronously. How can that be implemented?The RepoProviders should probably made aware of the auth info in order to be able to fetch private repositories, but are RepoProviders the right place to implement authorization / access controls ? If not, would a pre_build_hook as suggested in User hook for the build endpoint #1117 help?
Testing this PR locally
Install this branch of Binderhub locally using minikube as per the CONTRIBUTING instructions
Start minikube (e.g. run
minikube start --memory 8192
) and note the minikube IP (runminikube ip
)Register for an account at gitlab.com (user will be called
user1
)Create a private project
Create an application on gitlab.com ("settings" on your user profile) for authentication purposes (e.g.
bhubtest
).redirect URL
field, usehttp://<minikube ip>:30123/hub/oauth_callback
(note that the minikube IP may change when minikube restarts, usually alternating between two values. If so, put both in theredirect_uri
field to ease testing).api
andread_repository
scopes.read_api
now that gitlab offers this...Install the
requests
package (used by the example repo provider) e.g.pip install requests
change the file
testing/minikube/binderhub_auth_config.py
so that it looks like thistesting/minikube/jupyterhub-helm-auth-config.yaml
so that it looks like thisInstall jupyterhub by running
./testing/minikube/install-hub --auth
Run binderhub:
python3 -m binderhub -f testing/minikube/binderhub_auth_config.py
Access http://127.0.0.1:8585 using your browser. You will be prompted to login using gitlab.com
Authorize the application, you should end up at the familiar BinderHub UI (phew!)
Try building your private repository: in the provider dropdown, select gitlab.com and enter the "namespace" (user1/project) for your private project. Check that it builds and launches
Register a new gitlab user (
user2
), create a new private project for user2.Check that user2 can build its own private project, but not user1's
(Note that whenever the minikube IP changes due to a restart, the file
testing/minikube/jupyterhub-helm-auth-config.yaml
should be updated accordingly and./testing/minikube/install-hub --auth
should be run again)