- Notifications
You must be signed in to change notification settings - Fork673
Oauth token support#357
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
Happy to squash the linter issues & fixes. |
@nathschmidt Thank you for this patch! It looks good but I'm not sure how I can test it, I don't really have experience with oauth. I'm wondering if I can test on gitlab.com with auth from github. Any feedback on this? |
Hmmm, I'm not sure if you can chain the OAuth that way - worth a try. I've tested it against an in house gitlab-ee (v0.10) - with great success. |
OK, let's merge. It won't break the current private_token support, that's good enough for now. Thank you for resurrecting the topic@nathschmidt :) |
This is great, thanks! When do you think the next release will be? |
Addresses#163
Small change that adds support for Oauth tokens. Follows the same flow as the standard private token - instead of setting the
PRIVATE-TOKENheader setsAuthorization. Deprecated methods have not been updated/changed. Existing open PR's for this issue haven't been used as they're over a year old and the codebase seems to have changed rather dramatically.There's possibly a slight issue with providing both
private_tokenandoath_token, asprivate_tokenwill silently take precedence maybe a warning or error would be clearer. I think the chance of a user actually doing that is pretty slim though.I've verified against a v0.10 gitlab (v4 API). Shouldn't be any break to the existing interface.
Let me know if you've got any questions.