英文:
Debug redirect_url in oauth2 flow
问题
我们正在使用Go服务器端代码与Google Ads REST API进行交互。
具体来说，我们使用"golang.org/x/oauth2"和"golang.org/x/oauth2"包来进行身份验证。
在五月份（最近又一次），我们收到了Google发送的有关弃用Out-of-band流程的电子邮件，基本上是对这篇文章的重新表述。
但是除了常见的信息之外，Google的电子邮件还列出了我们用于身份验证的帐户正在使用OOB流程，并将被阻止。
我们检查了我们的源代码和提到的包的可用源代码，但没有找到用于OOB流程的重定向URI，其中包括：
- redirect_uri=urn:ietf:wg:oauth:2.0:oob
- urn:ietf:wg:oauth:2.0:oob:auto
- oob
我们在我们的代码中明确使用http://localhost和长期有效的刷新令牌（似乎永不过期）。
我们还尝试使用tcpdump来监视我们的API调用，但由于调用是通过https进行的，因此无法从中获取太多信息，因为它们是加密的。
我们考虑使用类似于https://www.charlesproxy.com/的中间人代理，但由于它变得收费，并且设置复杂，我们尚未尝试。
我们尝试使用自定义的RoundTripper记录我们对API端点的请求，但没有发现任何可疑的内容。似乎我们只使用刷新令牌，并且在代码中从code交换到refresh token的过程从未发生。因此，我们认为进一步记录或监视并解密https包可能不会有所帮助（但我们欢迎如何更好地进行此操作的建议）。
最后，我们决定在Google控制台中创建一个新的OAuth 2客户端，使用全新的客户端ID、客户端密钥和刷新令牌。我们使用oauth2l获取了一个新的刷新令牌，并在我们的配置中替换了凭据。但是，我们仍然不确定新帐户是否会因为OOB弃用而被Google阻止，因为它看起来与旧帐户相同。
问题：
- 为什么Google会将我们的帐户标记为OOB？
- 我们如何确保新创建的帐户不会被阻止？
英文:
We are using Go server side code to interact with Google Ads REST API.
Namely, we authenticate it with help of "golang.org/x/oauth2" and
"golang.org/x/oauth2"packages.
In May (and recently again) we've got a email from Google regarding deprecation
Out-of-band flow, essentially rewording of this
one.
But additionally to common information, Google email listed account, which we
are using to authenticate, as being used in OOB flow and going to be blocked.
We checked our sources and available sources of mentioned packages but was not
able to find redirect URIs which are said to be used for OOB flow as one of
those:
- redirect_uri=urn:ietf:wg:oauth:2.0:oob
- urn:ietf:wg:oauth:2.0:oob:auto
- oob
We explicitly use http://localhost in our code and long-live refresh token
(which seems never expires).
We also tried to use tcpdump to monitor our API calls, but was not able to
learn much from it, because calls are made via https and, therefore, encrypted.
We considered to use man-in-the-middle kind of proxy like
https://www.charlesproxy.com/, but haven't tried it yet, because it become
non-free and because of complexity of setup.
We tried to log our requests to API endpoint with custom RoundTripper, but
have not spotted anything suspicious. It seems that we're using refresh token
only and exchange of code to refresh token just never happen in the code.
Because of this, we don't think that further logging or monitoring with
decrypting https packages may help (but we open to suggestions how to do it better).
Finally, we decided to create a new OAuth 2 Client in the Google console with
fresh set of client id, client secret and refresh token. We obtained a new
refresh token with oauth2l and replaced
credentials in our configuration. But still, we are not sure that new account
will not be blocked by Google due OOB deprication, because seemingly it looks
the same as old one.
Questions:
- Why may Google mark our account as OOB?
- How can we ensure that newly created account will not be blocked?
答案1
得分: 1
我在这里。我发现一个答案，它说“桌面”类型的凭据默认使用OOB。可能你需要创建一个类型为“Web”的新凭据。
英文:
Same here.
I find out an answer, that says "Desktop" type of Credentials uses OOB by default. Probably you need to create new Credentials with type "Web"
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论