[Feature] support for Github API keys about bob HOT 16 CLOSED

Hmm that's fair enough, I'll try to add it but probably not very soon.

from bob.

@dhruvinsh What exactly are those token keys you are speaking of?

from bob.

Here we are using api to download neovim. One of the example is https://api.github.com/repos/neovim/neovim/releases/tags/nightly

For user who are not logged in get 60 call per hours to such api. And in corporate network that get exhausted quickly, so user need to use GITHUB_TOKEN to increase the limit to 5000 per hours. Kind of making authenticated call to the api, else bob would fail all the time.

Some details can be fine here.

from bob.

That's cool, but is there any situation a bob user would need to use this more than 60 times an hour?

from bob.

The limit is not apply to one specific link. Its a counter that applies to https://api.github.com

Then trailing url part could be anything, it could be bob, neovim other apps, anything.

As i said, in corporate network it exhausted quickly. Hope this explains everything. This is best guide for understanding, https://docs.github.com/en/rest/overview/resources-in-the-rest-api?apiVersion=2022-11-28

Update:
if someone have rate-limit applied from github the output would look like this,

bob update -a
Oct 13 09:23:19.659  INFO Fetching latest version
Oct 13 09:23:19.815 ERROR Error: invalid type: map, expected a sequence at line 1 column 0

from bob.

This issue mostly hits users in a corporate or large shared network where the rate limit is quickly exceeded.

In order to increase the GitHub API rate limit, it is necessary to authenticate in the request by supplying a token.

For example, with curl requests add:

--header "Authorization: Bearer YOUR-TOKEN"

You could specify an environment variable that must be set, say GH_TOKEN or GITHUB_TOKEN, and use that as YOUR-TOKEN above. That's what I do with my Neovim install script.

My two bits: It's important to work behind corporate networks. That is, this issue is high priority in my opinion. At least check if the above environment variables are set and, if so, add the header to the request.

As an aside, I love Bob! Thanks so much.

from bob.

@doctorfree so it can be specified either via config file or ENV VAR?

from bob.

@MordechaiHadad yes, it could be a new entry in ~/.config/bob/config.json or an environment variable. I prefer ENV VAR but support in a configuration file would be fine. For example:

// /home/user/.config/bob/config.json
{
  "enable_nightly_info": true, // Will show new commits associated with new nightly release if enabled
  "enable_release_build": false, // Compile neovim nightly or a certain hash version as a release build (slightly improved performance, no debug info)
  "downloads_location": "$HOME/.local/share/bob", // The folder in which neovim versions will be installed too, bob will error if this option is specified but the folder doesn't exist
  "installation_location": "/home/user/.local/share/bob/nvim-bin", // The path in which the used neovim version will be located in
  "version_sync_file_location": "/home/user/.config/nvim/nvim.version", // The path to a file that will hold the neovim version string, useful for config version tracking, bob will error if the specified file is not a valid file path
  "rollback_limit": 3, // The amount of rollbacks before bob starts to delete older ones, can be up to 225
  "github_mirror": "https://github.com" // github or github mirror
  "github_api_token": "xyxxydkkejrelidjkf" // Your GitHub API Token
}

I am not familiar with the guts of Bob. If the github_api_token configuration parameter is set then add the appropriate header to GitHub API requests.

I understand time constraints and priorities when maintaining projects. Please do not construe my comments as being anything other than suggestions and adopt or not at your own pace and time. Cheers!

from bob.

@doctorfree so it can be specified either via config file or ENV VAR?

Storing a TOKEN in a configuration file or env var is NOT safe, we should consider using the system password manager, in Rust, we can use the keyring crate

from bob.

@doctorfree so it can be specified either via config file or ENV VAR?

Storing a TOKEN in a configuration file or env var is NOT safe, we should consider using the system password manager, in Rust, we can use the keyring crate

How would that work exactly (never used keyring)

from bob.

How would that work exactly (never used keyring)

It basically behaves like a HashMap, you ask the user to input the GitHub token(probably a CLI option, like bob --set-up-token), insert it to the manager(you name the key), then you can get it when sending http requests to the GitHub

from bob.

You can take a look at this file if you wanna see how the API looks like

https://github.com/SteveLauC/pup/blob/main/src/operation/token.rs

from bob.

These all are viable option but not all the os supports same type of keyring mechanism. And as far as I know WSL do noth have these.

Hence my original proposal having it as only part of environment variable still much viable and secure option. No need to keep at as a part of config either.

And honestly how many people would going to use this anyway, very handful of people. Not everyone blocked behind an API. So looking for GITHuB_TOKEN variable is much simple and risk free implementation rather introducing any complexity.

from bob.

Yeah, WSL does not have this, you need a desktop environment or the corresponding service installed to make it work

from bob.

So what shall be the solution?

from bob.

So what shall be the solution?

As I mentioned in my comment, using environmental variables would be very secure. If its unsafe one can always run as inline,

GH_TOKEN=xbxnnxnxbxb bob update -a

And on the bob, all we need to do is if specific env variable found add extra header on the API calls.

Update:
did bit of the reading on the rust (I don't know anything about rust), we can implement env::var("GITHUB_TOKEN") and if found, rather then using Client::new() we need to use Client::builder() to have default header applied at the very beginning.

from bob.