Google 使用云 SQL 数据库预览或发布应用程序时，范围授权无限循环
Google Scope Authorizations Loop Endlessly When Previewing or Publishing Apps with Cloud SQL Database
大约一个月前，我的组织将 Cloud SQL 设置为 Google App Maker 的默认设置。在上周，我们无法预览或发布使用云 SQL 数据源的应用程序，包括之前运行良好的示例应用程序。失败发生在授权过程中。预览或发布应用程序时，Google App Maker 会显示一个对话框，说明 "Deploying this app requires authorization"。接下来它会提示用户输入他们的 Google 帐户，然后请求批准必要的授权（例如 "Manage the data in your Google SQL Service instances"）。批准授权后，授权提示重新开始，对话框显示 "Deploying this app requires authorization"。
观察：
我们在多台不同的计算机、网络和四个不同的用户帐户上重复了这个问题。
在 SQL 云控制台中，我们的云 SQL 实例显示正在为每个应用程序创建的新数据库以及新的特定于数据库的用户帐户
- 当我使用 phpMyAdmin
直接登录云 SQL 数据库时，所有数据库都按预期显示
- 其他不使用云 SQL 数据源的应用程序工作正常，包括使用托管在同一云 SQL 实例中的计算数据源的应用程序
- Cloud SQL 数据库的堆栈驱动程序日志中的唯一错误显示与数据库的 "INFO" 级通信错误（中止连接...读取通信数据包时出错）
- 我无法找到应用程序的 Stack 驱动程序日志，因为我无法预览或发布它们（任一选项都会向 Stack 驱动程序日志提供 link）
- 我们的 SQL 实例中现在大约有 20 个数据库（主要与简单的应用程序测试相关），我们在 SQL 中只使用了 10 GB 中的 1 GB space实例
- 我在 Google 问题跟踪器上没有看到任何相关问题 Google App Maker
对于解决此问题的检查内容的任何帮助或建议，我将不胜感激。
我向 Google 问题跟踪器发布了一个问题，Google 更正了该问题。如果此问题再次发生，他们还提供了解决方法。
这是 Google 开发团队在 Google 问题跟踪器上发布的回复：https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
- Contact someone in your domain with Admin powers for your Google for Business license.
- Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
- Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
- Identify the Organizational Unit of that Appmaker dev user and make a note of it.
- Under the Organization Units settings, locate the Organization Unit you identified above.
- Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
- Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
- Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
- Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
- Be sure to select ONLY the OU you intend to change.
- Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
- Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.
大约一个月前，我的组织将 Cloud SQL 设置为 Google App Maker 的默认设置。在上周，我们无法预览或发布使用云 SQL 数据源的应用程序，包括之前运行良好的示例应用程序。失败发生在授权过程中。预览或发布应用程序时，Google App Maker 会显示一个对话框，说明 "Deploying this app requires authorization"。接下来它会提示用户输入他们的 Google 帐户，然后请求批准必要的授权（例如 "Manage the data in your Google SQL Service instances"）。批准授权后，授权提示重新开始，对话框显示 "Deploying this app requires authorization"。
观察：
我们在多台不同的计算机、网络和四个不同的用户帐户上重复了这个问题。
在 SQL 云控制台中，我们的云 SQL 实例显示正在为每个应用程序创建的新数据库以及新的特定于数据库的用户帐户
- 当我使用 phpMyAdmin 直接登录云 SQL 数据库时，所有数据库都按预期显示
- 其他不使用云 SQL 数据源的应用程序工作正常，包括使用托管在同一云 SQL 实例中的计算数据源的应用程序
- Cloud SQL 数据库的堆栈驱动程序日志中的唯一错误显示与数据库的 "INFO" 级通信错误（中止连接...读取通信数据包时出错）
- 我无法找到应用程序的 Stack 驱动程序日志，因为我无法预览或发布它们（任一选项都会向 Stack 驱动程序日志提供 link）
- 我们的 SQL 实例中现在大约有 20 个数据库（主要与简单的应用程序测试相关），我们在 SQL 中只使用了 10 GB 中的 1 GB space实例
- 我在 Google 问题跟踪器上没有看到任何相关问题 Google App Maker
对于解决此问题的检查内容的任何帮助或建议，我将不胜感激。
我向 Google 问题跟踪器发布了一个问题，Google 更正了该问题。如果此问题再次发生，他们还提供了解决方法。
这是 Google 开发团队在 Google 问题跟踪器上发布的回复：https://issuetracker.google.com/issues/145345198
It's great to hear your up and working again! We are aware of this issue and are working through a longer term fix. The specific bug appears to be related to some changes made in the Google Cloud session policy control that may have rolled out to your domain recently interacting with AppMaker in a way that was not expected. We've spent time diagnosing the underlying issue and we beleive we know the root cause. I suspect your domain admin did a version of the workaround below.
Without getting too far into the details, the specific bug is that for a Deployer of an AppMaker application, if the Google Cloud Session policy is set with any expiration time, the returned token AppMaker sees is invalid, triggering a loop in AppMaker trying to generate a valid security token. Historically, these session tokens never expired but recently there was beta feature launch that allowed domain admins to set them to expire. We strongly suspect your domain recently set this expiration policy explicitly and that's what is causing the bug.
The good news is that these policies are overridable per Organizational Unit and we have tested that OUs which have the original classic Never Expire setting do, in fact, allow AppMaker to work.
My suspicion is that your domain admin has reverted recent, local changes to your organizational policy under the admin.google.com console, specifically under Security > Google Cloud session control (Beta).
If this happens again, here the workaround we would recommend. Note you don't need to do this if you're currently up and working. You will need the help of someone with admin.gogole.com powers, specifically User and Organizational Unit powers at your organization. It is a slight increase in security risk but it restores some classic behavior that was standard until recently.
The summary of the workaround is to override the Google Cloud session control expiration setting such that individuals who need access to AppMaker deployments can have it. To mitigate systemic security risk, this is best done by creating a limited purpose Organizational Unit with just that setting different than the parent OU settings.
The workaround is to:
- Contact someone in your domain with Admin powers for your Google for Business license.
- Have your admin proceed to https://admin.google.com. The actions below need to be performed by a domain admin.
- Under the Users section, identify the specific user account that needs the ability to deploy AppMaker Apps.
- Identify the Organizational Unit of that Appmaker dev user and make a note of it.
- Under the Organization Units settings, locate the Organization Unit you identified above.
- Create a new Organization Unit underneath that user's current Organizational Unit with some descriptive identifying it as special w.r.t AppMaker. So for Developers, make something like DevelopersWhoAreAlsoAppMakerDevs.
- Back under the Users tab, locate the user from step 3. Move this user into the new Organizational Unit you've just created. This change can take a while to propagate.
-Interlude- At this point, you've made a new Organizational Unit for just that individual and added them to it. You can certainly add multiple people to that OU, especially if they're already in the same parent OU. Use your discretion as to what amount of Organizational rework you wish to pursue. You may not be using OUs at all or you may decide to just turn off this control for the whole domain. It's up to you.
- Under admin.google.com's Security settings, locate the Google Cloud session control (beta) settings.
- Under this panel, from the dropdown menu on the left, locate the Organization Unit you just created.
- Be sure to select ONLY the OU you intend to change.
- Change the "Google Cloud Console and Google Cloud SDK session control" from expiring to "Session Never Expires".
- Save your changes.
The account you selected in step 3 should now be able to deploy AppMaker apps.
It appears this OU change is only necessary for the deployer of an AppMaker app, not an individual user. Note also that if you have multiple AppMaker developers who all have different current OU settings, you may need to create multiple daughter OUs to avoid a sudden radical shift in OU settings for an individual account.