Allow for Github API authentication

[tyler-8]

I recieved this error today while trying to pull down a gitignore file:

403: {"message":"API rate limit exceeded for <MY-IP>. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)","documentation_url":"https://developer.github.com/v3/#rate-limiting"}

So in environments where a lot of users might be behind one IP address (corporate proxy as an example) the unauthenticated API limits can be hit somewhat regularly. Perhaps using the locally configured git credentials would a good way around this.

[jamesharris-garmin]

do we have any intention to support this capability?

[CodeZombieCH]

Thanks for reporting this issue and sorry for the late reply.

Potential Solutions

I came up with the following solutions:

Authenticated Requests

Use unauthenticated requests until we hit the rate limit. If the rate limit is reached, offer the user to authorize using the OAuth device flow Store auth token using either:

• SecretStorage (see https://code.visualstudio.com/api/references/vscode-api#SecretStorage)
• new authentication API, required v1.54 (see https://code.visualstudio.com/api/references/vscode-api#authentication)

Pros

• Transparent for user and Github API

Cons

• This is expected to dramatically increase the time it takes for a user to successfully choose and download a gitignore template due to extra steps required to aquire an OAuth acces token:
  1. request device and user verification code
  2. ask the user to open https://github.com/login/device and enter the code
  3. poll for the user authentication status
• Token lifecycle management

gitignore Template Web Service

Create a simple web service that

• acts as a proxy to the gitignore repository
• can be used by this extension to list and download gitignore templates
• as an authenticated Github app has a rate limit of 5000 requests per hour (see https://docs.github.com/en/rest/overview/resources-in-the-rest-api#increasing-the-unauthenticated-rate-limit-for-oauth-applications)
• by itself does not have a rate limit

Pros

• No changes from a user perspective
• No additional time required

Cons

• Work to implement this service
• Additional costs to run the service

Conculsion

Both solutions could be implemented as gitignore providers. This would allow the user to choose the provider that best suits its setup using a provider selection dropdown in the extension settings.

Example:

@rlivings39 @tyler-8 @jimmyharris @jamesharris-garmin I would very much appreciate your thoughts about this

[CodeZombieCH]

With the new version v0.8.0 I introduced the GITHUB_AUTHORIZATION environment variable allowing you to specify the value for the Authorization HTTP header. Check the "Authenticated GitHub API Requests" section in the README.md

[dantman]

I don't think closing every vscode window and relaunching from a terminal with a manually created token is a great solution to this issue. It seems like even more work for the user than the first suggestion about OAuth token storage.

VSCode already has a system for handling GitHub authorizations. Which is used by the "GitHub Pull Requests and Issues", GitLens, and other VSCode extensions. Which the user will often already be signed in to and if not only needs to be setup once (the env var needs to be re-done every time in the future you start a project and need a .gitignore). I think this should just be used if the user hits the unauthenticated limit.

[CodeZombieCH]

Thanks for you feedback @dantman. I fully agree with you that environment variables are rather inconvenient.

I took a look the the "new" authentication providers introduced in July 2020 with version 1.48 and decided to try this approach. I'm currently working on a prototype that uses the following strategy:

• Use unauthenticated GitHub API requests
• If the rate limit is reached, prompt the user if he wants to authenticate using the built in GitHub authentication provider.

Will keep you posted.

[jamesharris-garmin]

Was there any progress on using the authentication providers? (been a while)