oauth2/google/appengine.go

39 lines
1.8 KiB
Go
Raw Normal View History

// Copyright 2014 The Go Authors. All rights reserved.
2014-09-03 14:50:43 -04:00
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
2014-06-17 09:53:08 -04:00
package google
import (
"time"
"golang.org/x/net/context"
"golang.org/x/oauth2"
)
appengine: implement AppEngineTokenSource for 2nd gen runtimes 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: 5779afb167d6abe13c29bb9632c9ac516a817e49 GitHub-Pull-Request: golang/oauth2#341 Reviewed-on: https://go-review.googlesource.com/c/146177 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-31 14:52:15 -04:00
// Set at init time by appengine_gen1.go. If nil, we're not on App Engine standard first generation (<= Go 1.9) or App Engine flexible.
var appengineTokenFunc func(c context.Context, scopes ...string) (token string, expiry time.Time, err error)
appengine: implement AppEngineTokenSource for 2nd gen runtimes 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: 5779afb167d6abe13c29bb9632c9ac516a817e49 GitHub-Pull-Request: golang/oauth2#341 Reviewed-on: https://go-review.googlesource.com/c/146177 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-31 14:52:15 -04:00
// Set at init time by appengine_gen1.go. If nil, we're not on App Engine standard first generation (<= Go 1.9) or App Engine flexible.
var appengineAppIDFunc func(c context.Context) string
appengine: implement AppEngineTokenSource for 2nd gen runtimes 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: 5779afb167d6abe13c29bb9632c9ac516a817e49 GitHub-Pull-Request: golang/oauth2#341 Reviewed-on: https://go-review.googlesource.com/c/146177 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-31 14:52:15 -04:00
// AppEngineTokenSource returns a token source that fetches tokens from either
// the current application's service account or from the metadata server,
// depending on the App Engine environment. See below for environment-specific
// details. If you are implementing a 3-legged OAuth 2.0 flow on App Engine that
// involves user accounts, see oauth2.Config instead.
//
// First generation App Engine runtimes (<= Go 1.9):
// AppEngineTokenSource returns a token source that fetches tokens issued to the
// current App Engine application's service account. The provided context must have
// come from appengine.NewContext.
//
appengine: implement AppEngineTokenSource for 2nd gen runtimes 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: 5779afb167d6abe13c29bb9632c9ac516a817e49 GitHub-Pull-Request: golang/oauth2#341 Reviewed-on: https://go-review.googlesource.com/c/146177 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-31 14:52:15 -04:00
// Second generation App Engine runtimes (>= Go 1.11) and App Engine flexible:
// AppEngineTokenSource is DEPRECATED on second generation runtimes and on the
// flexible environment. It delegates to ComputeTokenSource, and the provided
// context and scopes are not used. Please use DefaultTokenSource (or ComputeTokenSource,
// which DefaultTokenSource will use in this case) instead.
func AppEngineTokenSource(ctx context.Context, scope ...string) oauth2.TokenSource {
appengine: implement AppEngineTokenSource for 2nd gen runtimes 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: 5779afb167d6abe13c29bb9632c9ac516a817e49 GitHub-Pull-Request: golang/oauth2#341 Reviewed-on: https://go-review.googlesource.com/c/146177 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-10-31 14:52:15 -04:00
return appEngineTokenSource(ctx, scope...)
}