Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage of deprecated API #315

Closed
christianlupus opened this issue Mar 18, 2020 · 25 comments · Fixed by #323
Closed

Usage of deprecated API #315

christianlupus opened this issue Mar 18, 2020 · 25 comments · Fixed by #323

Comments

@christianlupus
Copy link

I just registered a new client in GitHub to gist. I got an email from GitHub with the following content:

Hi @christianlupus,

On March 18th, 2020 at 12:50 (UTC) you or an application you used recently accessed the deprecated Authorizations endpoint on the GitHub API with the useragent gist/5.0.0 (Net::HTTP, ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]).

We will remove the Authorizations API endpoint on November 13, 2020. If you accessed the API via password authentication, then we recommend you use the web flow to authenticate. Please check that your app uses the web flow for authentication https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow

You can learn more about these changes by visiting our developer blog https://developer.github.com/changes/2020-02-14-deprecating-oauth-auth-endpoint/

Thanks,
The GitHub Team

I just wanted to inform you of the fact that the gist tool might soon get problems to create new tokens.

@ConradIrwin
Copy link
Collaborator

ConradIrwin commented Mar 18, 2020 via email

@christianlupus
Copy link
Author

Just for reference: This is the relevant part in the source code. Unfortunately I am no fluent ruby developer and thus cannot help much here. Sorry.

@lumaxis
Copy link

lumaxis commented Mar 24, 2020

@christianlupus This should be fixed in 5.1.0, have you tried updating?

@christianlupus
Copy link
Author

I just updated and it seems that no deprecation notification is issued. However I just tested and it might be still on the route.
Closing here as it seems solved.

@KoviRobi
Copy link

I still have it, after doing gist --login

On March 31st, 2020 at 16:24 (UTC) you or an application you used recently accessed the deprecated Authorizations endpoint on the GitHub API with the useragent gist/5.1.0 (Net::HTTP, ruby 2.6.5p114 (2019-10-01) [x86_64-linux]).

We will remove the Authorizations API endpoint on November 13, 2020. If you accessed the API via password authentication, then we recommend you use the web flow to authenticate. Please check that your app uses the web flow for authentication https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow

You can learn more about these changes by visiting our developer blog https://developer.github.com/changes/2020-02-14-deprecating-oauth-auth-endpoint/

I think the other issue #310 was a slightly different deprecation notice.

@typebrook
Copy link

typebrook commented Apr 14, 2020

@KoviRobi

I think the other issue #310 was a slightly different deprecation notice.

Yes, you are right.

What 5.1.0 fixed with #308 is for:

  • Deprecation notice for authentication via URL query parameters (Check blog post here)
  • Already deprecated

This issue is about:

  • Deprecating notice for Authorizations API endpoint (Check blog post here)
  • Will deprecate on Nov.13

Authorizations API is still in use now, so this issue is not yet solved.
We still would get trouble on Nov.13.

@christianlupus please reopen this issue.

@typebrook
Copy link

typebrook commented Apr 15, 2020

@christianlupus @ConradIrwin @lumaxis @KoviRobi
Here is my proposal when using gist --login

  1. A prompt to ask user name and if they want to create a new token on a browser. If so, go to step 2. If not, go to step 3.
  2. Open https://github.com/settings/tokens/new?scopes=gist with default browser. So user can create a new token instantly.
  3. A prompt to ask user token

I am developing a bash script which has similar features to manage my gists (based on git workflow and GNU tools). It already implements the steps above to acquire user token, I think this way is workable.

output

The script is at https://gist.github.com/b0d2e7e67aa50298fdf8111ae7466b56, you may take a look.
How do you think about refactoring gist --login in this way?

@christianlupus
Copy link
Author

I think it should be usable. Especially as most gist users have a technical background.

@ConradIrwin
Copy link
Collaborator

Seems good to me, feel free to send a pull request :D.

@marlocarlo
Copy link

Please don't make opening a browser mandatory. I use it 99.9% of the timt through ssh. So, I need to open the browser remotely. It would be great if it displays the full link

@marlocarlo
Copy link

Hope the new Authentication method would support SSH so that it is possible to remotely open the link, login and then paste back the token.

@stgarf
Copy link

stgarf commented Jul 20, 2020

Yup, happened to me also when I went to reinstall the gist gem:

Hi @stgarf,

On June 30th, 2020 at 21:56 (UTC) you or an application you used recently accessed the deprecated Authorizations endpoint on
the GitHub API with the useragent gist/5.1.0 (Net::HTTP, ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.x86_64-darwin19]).

We will remove the Authorizations API endpoint on November 13, 2020.
If you accessed the API via password authentication, then we recommend you use the web flow to authenticate.
Please check that your app uses the web flow for authentication
https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/#web-application-flow

You can learn more about these changes by visiting our developer blog
https://developer.github.com/changes/2020-02-14-deprecating-oauth-auth-endpoint/

Thanks,
The GitHub Team

@ConradIrwin
Copy link
Collaborator

ConradIrwin commented Jul 20, 2020 via email

@mgmarino
Copy link

You can use the standard authorization code flow to do this, the github docs for this are here. I found an interesting blog post about how to handle this from a CLI here, basically:

  • Trigger a browser open to the authorize endpoint OR have the user paste it into the browser.
  • To receive the code, the app could spin up a local http server which would receive the redirect to 127.0.0.1:some_port (which would of course have to be registered with the client.)

To handle the case of doing this over ssh, I see two possibilities: either get the token manually, or, when logging in to the machine, tunnel the port that receives the redirect.

Seems like a fun little project, I'm afraid my ruby skills are almost certainly not up to the task. :-)

@ConradIrwin
Copy link
Collaborator

ConradIrwin commented Jul 21, 2020 via email

@mgmarino
Copy link

That's true, and the PKCE approach is as far as I know generally the way to deal with this "public clients" problem. Unfortunately, it seems github does not provide the needed code_verifier functionality to implement this extension.

@mgmarino
Copy link

Just had a look how the "official" github cli does it, indeed they use the flow without the PKCE approach:

https://github.com/cli/cli/blob/trunk/auth/oauth.go
https://github.com/cli/cli/blob/71bebd3f54f1c4006fa57a272382e8a285c9100c/internal/config/config_setup.go#L18

@ConradIrwin
Copy link
Collaborator

ConradIrwin commented Jul 21, 2020 via email

@lumaxis
Copy link

lumaxis commented Jul 28, 2020

Would this new flow be helpful for this particular use case? https://github.blog/changelog/2020-07-27-oauth-2-0-device-authorization-flow/

@ConradIrwin
Copy link
Collaborator

ConradIrwin commented Jul 28, 2020 via email

ConradIrwin added a commit that referenced this issue Jul 30, 2020
The username/password exchange mechanism is (rightfully) deprecated, the
device flow is now in beta, and seems to be the perfect replacement.

This change includes a best-guess of how this might work with GitHub
Enterprise but I haven't tested that, so GitHub Enterprise will continue
to default to the deprecated flow.

Fixes #315
@ConradIrwin
Copy link
Collaborator

I've put a potential fix up here: #323.

Is anyone able to test this on their machines? (it "works for me", but given that this API is in beta, I'd love some help testing).

Feedback welcome!

@lumaxis do you know how stable the device-flow is likely to be?

@typebrook
Copy link

@ConradIrwin
Works on my Linux machine, but there is a thing bother me: code need to include dash
For example, enter ABCD1234 cause error on https://github.com/login/device, only ABCD-1234 works.
Better to add a hint to remind user include - when doing gist --login

@stgarf
Copy link

stgarf commented Jul 30, 2020

Works here on macOS as well.

I found the output of gist --login to provide sufficient information ℹ️ to authorize the gist gem, for what it's worth.

@typebrook You should copy/paste the outputted code and not type it in manually to avoid the situation you described until github does some sort of form validation on that field to meet some sort of \d{4}-\d{4} regex.

@gwestersf
Copy link

I've put a potential fix up here: #323.

Is anyone able to test this on their machines? (it "works for me", but given that this API is in beta, I'd love some help testing).

Feedback welcome!

@lumaxis do you know how stable the device-flow is likely to be?

The API is in beta to reflect a feedback period where we can make enhancements. Our intent is to quickly move it to generally available. Given that we implemented this from an IETF spec, the API itself is stable. You can confidently develop with it. Multiple products at GitHub and Microsoft are using it as it is today, and some of them implemented the client flow before the server was ready -- with no changes at release.

@ConradIrwin
Copy link
Collaborator

Thanks @gwestersf, that's very encouraging! Thanks to you and anyone else who worked on this: the device flow was very simple to implement, and is much less scary to use than typing my password into the terminal!

There was one piece of UX feedback from @typebrook above that you might want to pass on (it's not obvious that the - is part of the token itself. I think this may be because it looks like entering a license key where the -s is just a visual separator to make it easier to remember).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants