Handle cases when hub api operation needs additional OAuth scopes

[mastoj]

I want to make it easier for our devs, data engineers and data scientist to work with gpg keys without know too much about them. One step in that would be to automate the upload of their gpg keys to github, or at least make a simple command they can run.

As of know I can't get it to work with hub.

Here's the command I want to run:

gpg --armor --export <email> | ./hub api user/gpg_keys -F "armored_public_key=@-"

I'm not sure why it doesn't work. I did download the repo and added some logging trying to figure out where it goes wrong, but failed to do so. The response I get is

{"message":"Not Found","documentation_url":"https://developer.github.com/v3/users/gpg_keys/#create-a-gpg-key"}

The actual request that hub generates looks the same as the one I created and tested with curl that works:

curl -v --request POST -H "Authorization: token $GH_TEST_TOKEN" https://api.github.com/user/gpg_keys --data '{"armored_public_key": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n....-----END PGP PUBLIC KEY BLOCK-----"}'

Also asked on SO: https://stackoverflow.com/questions/56324233/how-to-post-a-message-to-the-github-api-using-hub-api

[mastoj]

It seems to be something weird with authentication. If I modified the code and used a hard coded token like

req.Header.Set("Authorization", "token <token>")

in http.go file it worked. Not sure why it doesn't work with the token I got when logging in using hub.

[mastoj]

I think I found the reason to why I can't upload gpg key. This line here: https://github.com/github/hub/blob/master/github/client.go#L889 is explicitly setting the scope to repo. What is the reasoning behind this? Doesn't it make sense that you get more access as the default from an automation perspective. Or at least that you can provide the scope as argument and a log in command.

[mislav]

@mastoj Thanks for discovering this, and I'm sorry you had trouble. I guess your hub token would need the write:gpg_key for this to work. You can manually edit scopes for your "hub" token at https://github.com/settings/tokens, but I'm guessing you need a solution that lends itself better to automation.

Here are things we could improve around this:

• When a hub api command has failed due to insufficient OAuth token scopes, we should tell the user that this happened, tell them which exact scope they need to enable, and present them with the URL to edit the scopes at.

  Challenges: As you might have noticed from the error message, GitHub API isn't really friendly in reporting token scope problems. There is nothing in the “Not Found” error to indicate that it was your token that lacked insufficient scopes. Other endpoints might return similarly vague error messages. I'm not sure how we can implement this from within hub.

• Support requesting a hub token in the first place that has more scopes than just repo.

  Challenges: it would be great it there was a hub login, hub auth or a similar command to handle authentication in an interactive way that you could pass the additional scopes to via command-line parameters, but alas such a command doesn't exist yet, even though it was planned for a long time Dedicated command for authentication & configuration #225.

What are your ideas?

[mastoj]

I think yes please both thank you :). For debugging purpose it is very helpful to get a message of missing scopes, since it is a pain to figure out. I read through the source code to figure it out. And yes, would be good if there was an auth/login command. That could also be interactive the way that it is today the first time you run hub. I think it is fine to use `repo` as default, but it should allow a comma separated list of scopes you need.

…

On Wed, 29 May 2019 at 20:37, Mislav Marohnić ***@***.***> wrote: @mastoj <https://github.com/mastoj> Thanks for discovering this. I guess your hub token would need the write:gpg_key for this to work. You can manually edit scopes for your "hub" token at https://github.com/settings/tokens, but I'm guessing you need a solution that lends itself better to automation. Here are things we could improve around this: - When a hub api command has failed due to insufficient OAuth token scopes, we should tell the user that this happened, tell them which exact scope they need to enable, and present them with the URL to edit the scopes at. *Challenges:* As you might have noticed from the error message, GitHub API isn't really friendly in reporting token scope problems. There is nothing in the “Not Found” error to indicate that it was your token that lacked insufficient scopes. Other endpoints might return similarly vague error messages. I'm not sure how we can implement this from within hub. - Support requesting a hub token in the first place that has more scopes than just repo. *Challenges:* it would be great it there was a hub login, hub auth or a similar command to handle authentication in an interactive way that you could pass the additional scopes to via command-line parameters, but alas such a command doesn't exist yet, even though it was planned for a long time #225 <#225>. What are your ideas? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2147>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD2NMEOBTWDQGE5GWPVJ43PX3EPZANCNFSM4HP6L7ZA> .

[jamesstidard]

Hi,

I've just ran into this same problem, and had thought I was using the cli incorrectly before finding this ticket. The 404 is indeed a little misleading.

I'm also looking to automate setups of fresh machines and want to generate keys (ssh in my case) and upload them to the users GitHub account.

A login command (#225) would be good, though this would leave the hub oath token with these write keys permissions on the users machine which maybe is to privileged of a state. It would be nice to have the option for the login command to, instead of storing, hand back a auth token that can be stored in a temporary script variable to auth these types of high privileged commands, which can then be deleted at the end of the session. Leaving the system with no oath on the cli or the normal repos access rights.

[SuperSandro2000]

I also run into this problem when running hub fork for the first time and having already a token set via GITHUB_TOKEN env without the repo scope?

[kwhite]

+1 for this; Like @jamesstidard I am trying to automate provisioning new machines for my organization )(also with SSH keys) and would like to generate keys and upload them to the user's account.

I do like the idea of providing this as a temporary authorization so that hub isn't overprivileged on the machine for everyday operations. But less is more, and anything that gets me closer to being able to automate this process would be a win to my mind. :)