Support using an oauth token rather than a username+password #91

wants to merge 1 commit into


None yet
8 participants

ziz commented Apr 9, 2012

This is rather basic oauth token support. The most interesting part is probably the curl command to generate an oauth token that can create gists.

It should help address the security concerns in defunkt#84, though.


atmos commented Apr 9, 2012


@nandub nandub commented on the diff Apr 9, 2012

token = config("github.token")
- if password.to_s.empty? && !token.to_s.empty?

nandub Apr 9, 2012

gitjub.token doesn't work anymore. Do we need it here? I remove that code.


ziz Apr 10, 2012

It's being used here to warn about the change in authentication; removing it is out of the scope of this change.

jgoulah commented May 3, 2012

why hasn't this been merged? seems to work well

@weakish weakish commented on the diff May 3, 2012

@@ -56,9 +56,32 @@ the quick brown fox jumps over the lazy dog
-There are two ways to set GitHub user and password info:
+There are three ways to set GitHub authentication info:

weakish May 3, 2012


Three ways? password/oauth and env-var/git-config, 2*2=4.

Besides, is it necessary to support both password and oauth token?

jwhitley commented May 3, 2012

Requiring a manual curl call by the user is pretty rough, IMO.

I would recommend checking out @mislav's approach in the OAuth update to defunkt/hub:

That prompts the user for a password, then uses that only to retrieve and cache the OAuth token.

See also defunkt/hub#163

mislav commented May 3, 2012

I'm open to suggestions for extracting a small common utility that does it that hub and gist commands can share so we don't implement the same thing twice.

hub doesn't have external dependencies, so it would have to be a simple embeddable Ruby script.

ziz commented May 3, 2012

I agree; the curl call is miserable. My primary concern was getting the oauth functionality in place, but bringing a better experience to it would be well worthwhile.

mislav, the most general way that immediately occurs to me to split the token handler out would be a higher-level github API module than you have in hub - basically, only the api request functionality (get and post, and their underpinnings) and the capability to generate a token with the right permissions if one can't be found. That could then be the basis for the rest of your github API functionality, and start as the way to handle tokens in gist (but possibly move to standardize all of the git API handling in it as well). Thoughts?

mislav commented May 4, 2012

Here's the GitHub API client support code that I just released in hub. Maybe you can copy it over to gist, or mark "hub" gem as a dependency for gist (that wouldn't work when installed via brew, though).

The code is extremely modular and non-specific to hub. You could configure it to store oauth_token in "~/.config/gist".

If you have any feedback regarding my code (it's not perfect, quickly hacked together in order to ship), let me know.

rabbitt commented Feb 23, 2013

Try using my PR (#130) - it includes support for multiple API Providers (GH:E &, and includes functionality to auto-generate and store Github/GH:E credential (token) information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment