Use access tokens rather than id/secret about jupyterlab-github HOT 13 CLOSED

If you are using a different authenticator, you don't get a GitHub token for free.

We're using LDAP so that wouldn't work for us, nevertheless I think that will be very convenient for a large number of potential users.

GitHub does not have very granular permissions there.

Yeah, GitHub permissions have always been a bit of an issue. I'm hopeful Microsoft might improve the situation there now that they're in charge but I don't even know if it's on their radar.

from jupyterlab-github.

I wonder if, when setting up the oauth app, you need to select various permissions in order for this to work.

from jupyterlab-github.

I couldn't see anywhete/anyway to change permissions but I'll have another look.

When creating an access token a big permissions dialogue opens up and I granted it repo permissions.

Also, with a token there are no unused arguments such as a callback so it seems a better fit, unless the app capabilities might be required in future?

from jupyterlab-github.

Yes, I agree that it is a better fit. Perhaps we should make the access_token take precedence if it is defined?

from jupyterlab-github.

Trying again on GitHub and there's no way initially to specify permissions:

Instead, your app is supposed to make a request to GitHub to grant permissions:

...which IIUC will be redirected to an Authorize application dialog:

I really do think the OAuth app concept is a bad fit for what this extension is trying to do and while it can be shanghaied into simply providing access I'd be inclined to deprecate that authentication method if not just remove it entirely.

Unfortunately, I don't know any way to meaningfully deprecate a config value :| Maybe having both methods available for a release or two with the the access_token taking precedence will be sufficient.

from jupyterlab-github.

You are convincing me @dhirschfeld. I had hoped that it would be relatively straightforward to have an OAuth app that can be used for larger institutional deployments, but in practice I don't have the setup to properly test them.

You are looking into using this with an enterprise deployment, yes? How are you recommending users authenticate? Does each user create their own access token, or are you all crowding on one common one?

I think we should still keep the Oauth approach around for a couple of releases (deprecated) and then remove it before JupyterLab 1.0

from jupyterlab-github.

I had hoped that it would be relatively straightforward to have an OAuth app that can be used for larger institutional deployments

I see - the idea was that you'd only need one OAuth app rather than everyone having to create their own access token? I'm not sure that would work though in the case of different organizations - IIUC the app would only have permissions for the organization it was created under? Also, not sure if it would be a security concern having the client_secret visible to container users.

Yep, I've got a JupyterHub/JupyterLab deployment (on Windows containers!) and was hoping to make this extension available for everyone by default. It provides a very nice way for users to browse the GHE repositories they have access to and e.g. peruse example notebooks.

I think this extension is a very important piece of the puzzle in terms of making source control more accessible to users who are non-developers so thanks very much for much for your hard work in making it available!

I was thinking the next step in making source control more accessible would be a "Clone in JupyterLab" button. I think the binder button is great - binder is an amazing tool, but it doesn't make as much sense in an internal GitHub Enterprise environment.

On our GitHub Enterprise different teams have repos under different organizations so AFAICS each user will have to generate and use their own personal access token. There is one public organization, LearnPython that everyone has access to so my plan was to make that the official landing page and to provide information to the users how they can generate their own token to get access to their own organisations/repos. So that people would be able to access LearnPython by default I was going to generate a personal access token for a service account with read-only access to that organization.

from jupyterlab-github.

Yes, you are probably right that it would be a security concern to have client_secret available to users in that case. I am comfortable moving forward with the strategy in #47 and then removing the OAuth approach in the next release.

Thanks for sharing about how you are planning to use this, it is clarifying!

from jupyterlab-github.

Coming back to this over a year later because I'm now facing some deployment questions of my own. @dhirschfeld did you wind up deploying this to users? If so, have you established some good-practices around getting users to create-and-use access tokens in a JupyterHub setting? Any thoughts would be greatly appreciated.

from jupyterlab-github.

I haven't swung back to this though there were a number of unresolved issues I would like to revisit (probably in the upcoming months). One of those was the token story as it's currently not that obvious what a user needs to do.

I was thinking this could be ameliorated if the extension displayed a big warning that a PAT was missing, along with a brief description and a link (https://github.com/settings/tokens) to the page where they could be created. If you wanted to be cute you could even use jupyter-server-proxy to open the page inside jupyterlab itself (modulo any cors/iframe issues)

from jupyterlab-github.

I'm thinking about dusting off the idea of using a GitHub OAuth app, and trying to not leak the app ID to the user. In that case, it would just be a single app making the requests, which might be okay for smaller teams.

from jupyterlab-github.

@dhirschfeld I've made some progress on this front with a JupyterHub deployement using GitHub OAuth. It is reasonably straightforward to pass the authentication token from user login to this extension: https://github.com/CityOfLosAngeles/citywide-jupyterhub/blob/e010e49cf02ef42c4c9a237b6e9bc33d6a344288/deploy/config.yaml#L18-L42

There are two major downsides:

1. If you are using a different authenticator, you don't get a GitHub token for free. I think it would still be a good idea to extend this application to be able to pick up a token from an environment variable, so it could be set via other means.
2. If you want to view user-private repos, you need to ask for somewhat scary scopes in the OAuth process -- GitHub does not have very granular permissions there.

from jupyterlab-github.

Yeah, GitHub permissions have always been a bit of an issue. I'm hopeful Microsoft might improve the situation there now that they're in charge but I don't even know if it's on their radar.

Yeah, there is a very long-standing and popular issue for this: dear-github/dear-github#113

from jupyterlab-github.