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
Comments
Thanks! Pull requests welcome :D
P.S. Superhuman is hiring — referral bonus for Full Stack Engineers ( https://superhuman.com/roles?gh_jid=260350 ) : $1,947.
…On Wed, Mar 18, 2020 at 6:09 AM, Christian < ***@***.*** > wrote:
I just registered a new client in GitHub to gist. I got an email from
GitHub with the following content:
>
>
> Hi @ christianlupus ( https://github.com/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 (
> 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/
> (
> 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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (
#315 ) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/AAAXAQH5GJMS44AYJEHNGA3RIDBXXANCNFSM4LORCZJA
).
|
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. |
@christianlupus This should be fixed in |
I just updated and it seems that no deprecation notification is issued. However I just tested and it might be still on the route. |
I still have it, after doing
I think the other issue #310 was a slightly different deprecation notice. |
Yes, you are right. What
This issue is about:
Authorizations API is still in use now, so this issue is not yet solved. @christianlupus please reopen this issue. |
@christianlupus @ConradIrwin @lumaxis @KoviRobi
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. The script is at https://gist.github.com/b0d2e7e67aa50298fdf8111ae7466b56, you may take a look. |
I think it should be usable. Especially as most gist users have a technical background. |
Seems good to me, feel free to send a pull request :D. |
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 |
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. |
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 |
Does Github support a client-side based Oauth2 flow? That would be perfect.
Otherwise we can give out the instructions to users as instructed above,
Conrad
…On Mon, Jul 20, 2020 at 1:59 AM, stgarf < ***@***.*** > wrote:
Yup, happened to me also when I went to reinstall the gist gem:
Hi @ stgarf ,
On June 30 th , 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.3 p62
( 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 (
http://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/
(
http://developer.github.com/changes/2020-02-14-deprecating-oauth-auth-endpoint/
)
Thanks ,
The GitHub Team
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#315 (comment) ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/AAAXAQAQKNF7FP74OSDHOIDR4QBNVANCNFSM4LORCZJA
).
|
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:
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. :-) |
Interesting, in order for that to work, we'd have to bundle a shared "client_secret" with the published gem – at which point it wouldn't be a secret anymore. I know that's usually considered a flaw by Oauth providers such as Google and Microsoft, but I'm not sure how Github views that situation
Conrad
…On Mon, Jul 20, 2020 at 11:40 PM, Michael Marino < ***@***.*** > wrote:
You can use the standard authorization code flow to do this, the github
docs for this are here (
https://docs.github.com/en/developers/apps/authorizing-oauth-apps#web-application-flow
). I found an interesting blog post about how to handle this from a CLI here
( https://developer.okta.com/blog/2018/07/16/oauth-2-command-line ) ,
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. :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#315 (comment) ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/AAAXAQFJ475HEHGO32LKAPTR4UZ6ZANCNFSM4LORCZJA
).
|
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 |
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 |
Thanks for the research. It seems like we have a good path forward copying their approach.
I'll see if I can get my ruby development environment going this weekend and switch it up, if someone else gets there first, pull requests welcome :)
Conrad
…On Tue, Jul 21, 2020 at 11:43 AM, Michael Marino < ***@***.*** > wrote:
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/trunk/auth/oauth.go )
https:/ / github. com/ cli/ cli/ blob/ 71bebd3f54f1c4006fa57a272382e8a285c9100c/
internal/ config/ config_setup. go#L18 (
https://github.com/cli/cli/blob/71bebd3f54f1c4006fa57a272382e8a285c9100c/internal/config/config_setup.go#L18
)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#315 (comment) ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/AAAXAQDWE5YWVI75LO7A463R4XOUZANCNFSM4LORCZJA
).
|
Would this new flow be helpful for this particular use case? https://github.blog/changelog/2020-07-27-oauth-2-0-device-authorization-flow/ |
Ooh, seems perfect. Nice!
…On Mon, Jul 27, 2020 at 5:29 PM, Lukas Spieß < ***@***.*** > wrote:
Would this new flow be helpful for this particular use case? https:/ / github.
blog/ changelog/ 2020-07-27-oauth-2-0-device-authorization-flow/ (
https://github.blog/changelog/2020-07-27-oauth-2-0-device-authorization-flow/
)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub (
#315 (comment) ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/AAAXAQERHU5YBKHKNQV3LGLR5YLYBANCNFSM4LORCZJA
).
|
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 |
Works here on macOS as well. I found the output of @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 |
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. |
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 |
I just registered a new client in GitHub to
gist
. I got an email from GitHub with the following content:I just wanted to inform you of the fact that the gist tool might soon get problems to create new tokens.
The text was updated successfully, but these errors were encountered: