Feat: Basic Authentication for Github API

[jSadoski]

Description

At this time, we're having issues hitting rate limits - especially when testing. GitHub only allows 10 requests/minute. Basic Authentication would allow up to 30/minute.

Why is it necessary? (or how would it make it better)

This is necessary to expand our ability to perform automated tests without those tests failing due to Rate Limit issues.

how do you think should it be implemented? (If possible)

I think we should use a username/api key in the request header for Basic Authentication. We could then just place the appropriate credentials in an environment variable and use click to access it. We could also cache the username/api key, which I presume we would want to do securely... Not sure how to do that without external modules or if our automated testing would support that.

I would love to work on this! I don't know much about the automated PR testing, however. I would need to know if we can run it with the env variable and which account credentials we would use for testing.

[hedyhli]

Thanks for putting up the issue, I had been thinking about prompting the user for API token if rate limit is hit and use it with request headers but didn't have the time. Using environment variables so it can be used in pytests is a great idea!

We could first implement the checking if rate limit is hit, and prompt the API token from the user, which can be generated from here (got the idea from githunt :D), and then use the token to be added in the header param like this (I know it's JavaScript but the header data is the same). Although using username/password instead of a token would also work, not sure which one would be better.

Details of implementation, just for inspiration

• for prompting we could use rich.prompt for checking length/chars etc
• it seems that status code 403 is returned when rate limit is hit
• Storing the credentials in something like a data.json should be enough, because the user is only supposed to allow public repo access for the token, although we could also hash it for security

[jSadoski]

So I already got a personal token and I was able to use it with the addition of the requests-oauthlib package, so that works.

Maybe we should just start by making it an option like --auth username:token, then we could add the feature with rich to prompt once that's built in?