I missed this in CL 146677.
Change-Id: Ie2735ba15d41e51fd5a99cba97514cd16399abaa
Reviewed-on: https://go-review.googlesource.com/c/147458
Reviewed-by: Ross Light <light@google.com>
Assume Go 1.9+, which is broader than Go's current Go 1.10+ support policy.
Change-Id: I9fe6954d21c2279cf4ea7da4d5bc7a9290a3bae2
Reviewed-on: https://go-review.googlesource.com/c/146677
Reviewed-by: Ross Light <light@google.com>
PR #341 introduce some new import `x/net/context` in parallel of PR #339 replacing them with the standard context.
This quick PR rename those imports.
Change-Id: I94f7edbee851a733b8a307c2ea60923dd990bdb4
GitHub-Last-Rev: fbe7944356
GitHub-Pull-Request: golang/oauth2#342
Reviewed-on: https://go-review.googlesource.com/c/146837
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go 1.11 on App Engine standard is a "second generation" runtime, and
second generation runtimes do not set the appengine build tag.
appengine_hook.go was behind the appengine build tag, meaning that
AppEngineTokenSource panicked on the go111 runtime, saying,
"AppEngineTokenSource can only be used on App Engine."
The second gen runtimes should use ComputeTokenSource, which is also
what flex does [1]. This commit does two things to remedy the situation:
1. Put the pre-existing implementation of AppEngineTokenSource behind
the appengine build tag since it only works on first gen App Engine
runtimes. This leaves first gen behavior unchanged.
2. Add a new implementation of AppEngineTokenSource and tag it
!appengine. This implementation will therefore be used by second gen
App Engine standard runtimes and App Engine flexible. It delegates
to ComputeTokenSource.
The new AppEngineTokenSource implementation emits a log message
informing the user that AppEngineTokenSource is deprecated for second
gen runtimes and flex, instructing them to use DefaultTokenSource or
ComputeTokenSource instead. The documentation is updated to say the
same.
In this way users will not break when upgrading from Go 1.9 to Go 1.11
on App Engine but they will be nudged toward the world where App Engine
runtimes have less special behavior.
findDefaultCredentials still calls AppEngineTokenSource for first gen
runtimes and ComputeTokenSource for flex.
Fixes#334
Test: I deployed an app that uses AppEngineTokenSource to Go 1.9 and
Go 1.11 on App Engine standard and to Go 1.11 on App Engine
flexible and it worked in all cases. Also verified that the log
message is present on go111 and flex.
[1] DefaultTokenSource did use ComputeTokenSource for flex but
AppEngineTokenSource did not. AppEngineTokenSource is supported on flex,
in the sense that it doesn't panic when used on flex in the way it does
when used outside App Engine. However, AppEngineTokenSource makes an API
call internally that isn't supported by default on flex, which emits a
log instructing the user to enable the compat runtime. The compat
runtimes are deprecated and deploys are blocked. This is a bad
experience. This commit has the side effect of fixing this.
Change-Id: Iab63547b410535db60dcf204782d5b6b599a4e0c
GitHub-Last-Rev: 5779afb167
GitHub-Pull-Request: golang/oauth2#341
Reviewed-on: https://go-review.googlesource.com/c/146177
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
PKSC1 is not a thing, but PKCS1 is, and the parse function above the
error is for PKCS1.
Change-Id: I163bb158070da462caa034a19a89ce654acc7a5d
Reviewed-on: https://go-review.googlesource.com/c/146178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This removes any assumption about how the underlying TokenSource is
implemented.
Change-Id: I03521e2f26bd07e25eb6ba00a78c285ece1835cc
Reviewed-on: https://go-review.googlesource.com/114955
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fix for a small bug that causes scopes to be prefixed by a bunch
of `+` chars, which results in an invalid scopes response from
the Jira Auth Server.
Change-Id: I00ded66c1eeb042a02f11ef3c84d7281159b1039
GitHub-Last-Rev: f76f480589
GitHub-Pull-Request: golang/oauth2#282
Reviewed-on: https://go-review.googlesource.com/110917
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Support obtaining a DefaultCredentials value from JSON data.
Also, add an example, and write more package doc.
For Go 1.9 and higher, rename DefaultCredentials to
Credentials and make the former an alias for the latter.
Updates google/google-api-go-client#247.
Change-Id: I9f9e234ed79f8e08fa13914d9c6c60e0154a06e5
Reviewed-on: https://go-review.googlesource.com/99795
Reviewed-by: Ross Light <light@google.com>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A friend who now works at Facebook informs me that this is now fixed on their
side. I've asked for some public reference.
Change-Id: I68627e3211f24bc4bea7c698d1126438a0e8ab0d
Reviewed-on: https://go-review.googlesource.com/97055
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Auth0 does not support `client_id` in basic auth
**without** a `client_secret` but they do support
one or both in the body.
Auth0 also uses account specific subdomains, so
needs to be in the domain suffix broken handling.
Change-Id: I06abec5c228c746b8b90758f452016eeb67f3e98
Reviewed-on: https://go-review.googlesource.com/70010
Reviewed-by: K.J. Valencik <kjvalencik@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This function added a totally unused error path, since the only call
site is for App Engine, which cannot produce an error.
Change-Id: I86277ab4ff96e7bd140c53c5a114a338716668e3
Reviewed-on: https://go-review.googlesource.com/85935
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This behavior and test was introduced in 0ae3d4edc9.
It is not consistent with the other test introduced in the same commit,
where an incorrectly typed access_token does produce an error. Since a
*Token with a blank AccessToken is invalid, it is allowing an invalid
token to be returned without error.
Cleans up some tests responding with invalid data.
Change-Id: I777eb7a82ef598dc9042542ae65f8dce6768902e
Reviewed-on: https://go-review.googlesource.com/85659
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This changes the test to use the exported API instead of implementation
internals.
Change-Id: I07753b053c1a2a8eb027bed647ab921d95afda4e
Reviewed-on: https://go-review.googlesource.com/85658
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This was the only usage of the function.
Change-Id: I081e20789ea9e37fe96f764641078472153bf577
Reviewed-on: https://go-review.googlesource.com/85197
Reviewed-by: Andrew Bonventre <andybons@golang.org>
CL 84156 added oauth2.RetrieveError to the oauth2 and clientcredentials
packages, but missed using it in jwt.
Change-Id: I06d77cd18667526bfc869ebc1b5cc2bcbabc03a6
Reviewed-on: https://go-review.googlesource.com/85457
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Allows the HTTP response and body to be extracted without parsing
the error string, but keeps backwards compatibility for users who
are currently doing so.
Fixesgolang/oauth2#173
Change-Id: Id7709da827a155299b047f0bcb74aa8f91b01e96
Reviewed-on: https://go-review.googlesource.com/84156
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Mail.Ru is one of the most popular email service provider in Russia.
The documentation for Mail.Ru's OAuth2 endpoints is at
https://o2.mail.ru/docs/
Change-Id: I605979b85cff2b00c7b65bbd3306d3fa66faa56d
Reviewed-on: https://go-review.googlesource.com/84415
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Maruf
huy le
lalyos
Adam Shannon
Brad Fitzpatrick
Filip Stanis
Antoine GIRARD
Michael Traver
Travis Bischel
Fredrik Wallgren
Steve LoFurno
Jeremy
Peter Hoyes
a.lukinykh
Manigandan Dharmalingam
Guillaume J. Charmes
Val Polouchkine
Tim Cooper
Sebastien Binet
Dong-hee Na
Getulio Sánchez
Benjamin Hsieh
Naveen Kumar Sangi
Shaun Dunning
fenwickelliott
Bob Briski
Andrew Bonventre
Jonathan Amsterdam
Tristan Colgate
Paul Tyng
Adam Bender
Ross Light
Vladimir Varankin