Open ashi009 opened 7 months ago
I don't quite understand what is being proposed here. Is it the idea of handling auth in go-github itself to save from having to bring in third party dependencies or is it something bigger that looks at the endpoint being called and chooses the right kind of authentication to use?
Both.
Hmmm... one of the things we try hard to do in this repo is keep the dependencies to an absolute minimum. I'm not sure that we really want to pull in JWT manipulation code as a dependency here. I'm fine with adding examples that pull in those dependencies, but not as helpers in the main repo if we can avoid it.
In fact, this exact conversation is how the ghinstallation
repo was originally started as an external helper repo.
If you want that kind of functionality, we prefer that it is implemented in an external repo and we are happy to point to it from this repo as an example of usage.
I agree with what @gmlewis is saying, but it would still be interesting to explore this idea as a whole. Then we can see if there is a way to make it work that is feasible to maintain.
@ashi009 I'm especially curious to see your ideas of making it easier to switch between creds. Do you have suggestions of what the API changes would look like?
As somebody who occasionally uses app and installation authentication, one thing I struggle with is keeping track of which endpoints require which creds. I have a rough idea that this could be improved, but I haven't proposed anything. I only occasionally dabble in apps so I feel like I don't have a full understanding of the problem.
Many of the apis requires to be invoked as Github App, eg. https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28. And currently we need to use third-party packages like ghinstallation to do so.
However, this is not the full story. When creating a Github App, it involves many different kinds of creds:
And we need to use different cred to call different APIs. For now, the only way to do so is to create many different
github.Client
s, each holding a different credential.And we need to do this with extra care, as all these token are short-lived, and need to be cached/refreshed periodically. Which means, blindly creating those clients will cause lots of rate limiting issues.
For instance, to use
github.ChecksService
, we need:
- Auth as Github App itself by creating a JWT with app's private key, to call
github.AppServiceCreateInstallationToken
- Once we have the token, we can auth as app installation, then calling
github.ChecksService
Which requires 2
github.Client
s in total.
Hello @ashi009 I faced the same situation and I created a similar issue #3178.
Thread discussion with @gmlewis led to creating a new package to handle this functionality. https://github.com/jferrl/go-githubauth. Just take a look, its compatible with golang.org/x/oauth2 oauth2.TokenSource
and could be used with oauth2.ReuseTokenSource
to handle token refreshing.
Many of the apis requires to be invoked as Github App, eg. https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28. And currently we need to use third-party packages like ghinstallation to do so.
However, this is not the full story. When creating a Github App, it involves many different kinds of creds:
And we need to use different cred to call different APIs. For now, the only way to do so is to create many different
github.Client
s, each holding a different credential.And we need to do this with extra care, as all these token are short-lived, and need to be cached/refreshed periodically. Which means, blindly creating those clients will cause lots of rate limiting issues.
For instance, to use
github.ChecksService
, we need:github.AppServiceCreateInstallationToken
github.ChecksService
Which requires 2
github.Client
s in total.