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>
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>
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>
Before AppEngine classic allowed "google.golang.org/appengine" imports,
we used to maintain two hook files to choose either from "appengine" or
"google.golang.org/appengine" namespaces. Now, both environments allow
importing from "google.golang.org/appengine". Therefore, there
is no need to set hooks in two separate files.
Also note that Flex prefers to use metadata server, so we still
need to be able to differentiate between these environments.
Change-Id: I7478ebdfa1b062d466aaf2aca938f93d42b4c58a
Reviewed-on: https://go-review.googlesource.com/37378
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Due to an issue in handling thread-local storages, os/user can lead to SEGV
when glibc is statically linked with.
So we prefer os.Getenv("HOME") for guessing where is the home directory.
See also: golang/go#13470
Change-Id: I1046ff93a71aa3b11299f7e6cf65ff7b1fb07eb9
Reviewed-on: https://go-review.googlesource.com/34175
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This new function allows reading the project ID from a service account
JSON file without an additional disk read.
Change-Id: I1f03ca3ca39a2ae3bd6524367c17761b0f08de45
Reviewed-on: https://go-review.googlesource.com/32876
Reviewed-by: Jaana Burcu Dogan <jbd@google.com>
The ADC code and the JWT-parsing function operate on the same data
format, but were using separate code paths, each of which was missing
things from the other.
While this presents no change in API surface, JWTConfigFromJSON now
strictly checks the "type" field in the JSON file before building a
config.
Change-Id: I2f593a16bf4591059fbf9002bccea06e41e5e161
Reviewed-on: https://go-review.googlesource.com/32678
Reviewed-by: Jaana Burcu Dogan <jbd@google.com>
go vet reports the following warnings:
google/jwt_test.go:85:
missing argument for Fatalf("%q"): format reads arg 2, have only 1 args
google/sdk_test.go:28:
wrong number of args for format in Errorf call: 1 needed but 2 args
Change-Id: If5acfae42b558ced7694dd7bc6f12ab4a3cb6115
Reviewed-on: https://go-review.googlesource.com/24992
Reviewed-by: Jaana Burcu Dogan <jbd@google.com>
The Raw (unpadded) version of URL encoding was introduced in Go 1.5.
Since we no longer need to support Go 1.4 (and indeed, Go 1.4 won't work
because of our dependency on golang.org/x/net/context), we can simplify
the base64 encoding/decoding to use this directly.
Fixesgolang/oauth2#190.
Change-Id: Ic2676edf5fe5b4d1680409fd9c02bd1c287ca39f
Reviewed-on: https://go-review.googlesource.com/25000
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Managed VM apps can use the net/http package directly, and can use the
metadata server instead of the appengine package to get Service Account
tokens.
Change-Id: Ifa30eea446ffe4a9121ce3401900f4b73ddf07db
Reviewed-on: https://go-review.googlesource.com/14125
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is a new form of authentication for Google services, where instead
of passing a signed claim to obtain a token from the OAuth endpoint, you
present the signed claim *as* the token to the API endpoint.
Fixes#139.
Fixes#140.
Change-Id: Ibf0f168a0ec111660ac08b86121c943fb96e146c
Reviewed-on: https://go-review.googlesource.com/10667
Reviewed-by: David Symonds <dsymonds@golang.org>
Reviewed-by: Dave Day <djd@golang.org>
Google is moving toward a default, language-agnostic way of obtaining
authentication credentials on App Engine and Compute Engine.
This change implements this mechanism.
Fixes#90.
Change-Id: Iaae4d60bbc75b1a9f2ec6ad14ab76fb2e279d756
Reviewed-on: https://go-review.googlesource.com/6074
Reviewed-by: Burcu Dogan <jbd@google.com>
client_credentials.json may contain credentials for the installed
applications. Populate the Config depending on what's available in
the JSON key.
Change-Id: I47f494f1c31967a920fe557a9e8c1c4652943c4e
Reviewed-on: https://go-review.googlesource.com/7250
Reviewed-by: Andrew Gerrand <adg@golang.org>
You can now use the "google.golang.org/appengine" packages on both
Managed VMs and App Engine Classic(TM). The newer packages use the
context.Context instead of appengine.Context, so we no longer need the
oauth2.Context type.
Some clients will require code changes, replacing oauth2.Context or
appengine.Context with context.Context (imported from
the repository "golang.org/x/net/context").
Users of classic App Engine must switch to using the new
"google.golang.org/appengine" packages in order to use the oauth2
package.
Fixes#89
Change-Id: Ibaff3117117f9f7c5d1b3048a6e4086f62c18c3b
Reviewed-on: https://go-review.googlesource.com/6075
Reviewed-by: Burcu Dogan <jbd@google.com>
google.NewCloudSDK fails to decode credentials file if it contains
service account.
NOTE: the private key in testdata is generated only for this test.
Fixes#86 (https://github.com/golang/oauth2/issues/86).
Change-Id: I9e9e8e10763723d1bf1f953b491aa6e6f3ee760c
Reviewed-on: https://go-review.googlesource.com/4220
Reviewed-by: Andrew Gerrand <adg@golang.org>
This follows the change to the google.golang.org/appengine packages
to use the standard context.Context type throughout.
Change-Id: I91b456105ee29f2088c3646145ea0a940f8ffaf4
Reviewed-on: https://go-review.googlesource.com/3172
Reviewed-by: Burcu Dogan <jbd@google.com>
Reviewed-by: David Symonds <dsymonds@golang.org>
Token caching is now done whenever you make a Client, and
ReuseTokenSource is exported from the oauth2 package and used by the
Google TokenSources (Compute and App Engine).
Token.Expired is now Token.Valid, and works on nil receivers.
Some other wording cleanups in the process.
All tests pass. App Engine should pass, but is untested.
Change-Id: Ibe1d2599ac3ccfe9b399b1672f74bb24cfc8d311
Reviewed-on: https://go-review.googlesource.com/2195
Reviewed-by: Burcu Dogan <jbd@google.com>
- Removed Flow, flow is a nothing but options.
- Renamed Cacher to Storer.
- Removed the setter from the Transport. Store should do the initial set.
Getter is not removed, because extra fields are available through
Transport.Token.Extra(). It's not pleasant to implement a custom Storer
implementation to read such values.
oauth2: Remove VMs from the AppEngine example title
- Reduce the duplicate code by merging the flows and
determining the flow type by looking at the provided options.
- Options as a function type allows us to validate an individual
an option in its scope and makes it easier to compose the
built-in options with the third-party ones.
This change is for both App Engine and Managed VMs so that these apps can scale without running into the app_identity_service quota limit due to calling appengine.AccessToken too frequently. An added benefit of caching is that calls to Google APIs will be significantly sped up due to removing the round-trip calls to the api_identity_service.
Without a fully qualified domain name, containers (like Docker) can't
connect to the metadata server. Update the address for the metadata
server to be a FQDN so containers can use the library. See #44.
GAE managed VM runtime contains both appengine and appenginevm
build tags. Currently, appengine.go is being built even if user
wants to use the package on managed VM that errors with no
"appengine" package to import.