如果范围发生变化而又不影响生产的情况下，如何重新提交Google OAuth验证 [英] How to resubmit for google oauth verification if changes in scope without disturbing the production

问题描述

我的gmail扩展程序已成功运行，并且拥有大量用户.现在，我向其中添加了一些新功能，这些功能需要一些额外的受限gmail权限.由于这是一个扩展，因此如果我在不对新范围进行验证的情况下部署了新的更改，则将使用扩展的新功能的用户(新老用户)都将看到未验证的同意屏幕.

I have my gmail extension running successfully with some good number of users. Now I've added some new functionality to that which require some additional restricted gmail permissions. As this is an extension, so if I deploy new changes to that without verification of new scope, users (new and old both) who will use new functionality of extension will see unverified consent screen.

因此，我想知道是否可以在使用生产版本时完整地提交开发或测试应用程序以进行oauth验证.同样在扩展的情况下，我无法向正在生产的扩展添加部署新功能，因此如何向Google提供新功能扩展代码以供审核.

So, I want to know if it's possible to submit dev or test app for oauth verification, while using production version keep intact. Also in case of extension I can't add deploy new features to extension which is in production, so how to provide new feature extension code to google for reviewing.

推荐答案

您有几种不同的选择:

[1]使用增量身份验证.如果添加了新功能，则应该有一条单独的路径，您可以通过该路径向用户发送请求新作用域的路径. https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth然后，您可以请求对您在Google Cloud Developer控制台上注册的新范围进行应用验证.

[1] Use incremental auth. If you have added new functionality, then there should be a separate path you can send users through that will request the new scopes. https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth You can then request app verification for the new scopes you register on the Google Cloud Developer Console.

[2]标记保护您的更改(确保您的更改在实验之后)，在此您可以控制谁可以看到新行为.然后，您可以请求对您在Google Cloud Developer控制台上注册的新范围进行应用验证.

[2] Flag protect your changes (make sure your changes are behind an experiment), where you control who will see the new behavior. You can then request app verification for the new scopes you register on the Google Cloud Developer Console.

[3]如果您打算在扩展的版本之间切换，每个版本都由一个单独的OAuth客户端ID或什至一个单独的GCP项目编号表示，那么您当然可以使用新的OAuth客户端ID来实现新行为并提交您的应用以验证新客户ID所属的项目.

[3] If you intend to switch between versions of your extensions, where each version is represented by a separate OAuth client ID or even a separate GCP project number, then you can certainly implement the new behavior using a new OAuth client ID and submit your app for verification for the project that your new client ID belongs to.

请注意，对于所有选项，除非您请求对新范围的授权，否则已经记录了您的旧范围的授权的任何现有用户都不应中断.

Note that for all options, any existing users who have already recorded grants for your old set of scopes should not be disrupted unless you request authorization for the new scopes.

这篇关于如果范围发生变化而又不影响生产的情况下，如何重新提交Google OAuth验证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！