在过去的几个月中，我已经熟悉谷歌应用程序脚本中的OAuth2.0授权，但最近的异常让我感到困惑。我有一个独立的Web应用程序，作为融合表的前端。 Web应用程序被设置为'执行为'脚本和融合表所有者，融合表授予对外部用户的查看访问权限。该程序检测授权，如果需要提示，并使用刷新令牌（如果可用）。从拥有脚本和融合表的帐户运行时，一切正常。当'执行应用程序为我'时Google API授权。

一旦我发布了网络应用程序，我测试了它从外部帐户，它工作正常。刷新标记然后从脚本所有者的UserProperties中移除。当应用程序从外部帐户再次运行时，它会提示授权并正确授权（将新标记保存在脚本所有者的UserProperties中）。但是，对API的下一次POST调用收到403-Forbidden错误。此时，应用程序将继续从任何帐户（包括脚本所有者的帐户）收到403-Forbidden错误，直到令牌被手动清除并作为脚本所有者重新授权为止。

为什么这些令牌无效？我希望，由于应用程序正在作为脚本/融合所有者执行，所以以编程方式接收的任何令牌都将与脚本/融合所有者授权的令牌一样有效。如果我的期望不正确，我怎样才能防止多用户的这种情况发生？

更新

我已经获得了这方面的一些更多的牵引力，并已确定，我想在这里分享一些相关的问题。首先，我手动删除了令牌（刷新和访问），以测试应用程序授权的能力。后续授权未返回刷新令牌（导致过度提示）。我发现这是来自google API的故意结果。除了requisite request parameters返回刷新令牌之外，我发现刷新令牌只在第一个用户提示和授权（ref. here）上返回。为了获得另一个刷新令牌，您需要revoke-acess和重新授权或请求中的force the approval prompt。一旦我确定它变得更清楚，该标记被“附加”给发出初始授权请求的用户。只要我保留由脚本/表所有者获取的刷新令牌，那么脚本可以由任何外部用户使用（并且使用刷新令牌以编程方式重新授权）。这让我回到了这一点。如果我失去刷新令牌，我需要手动删除所有剩余的令牌碎片，以脚本/表所有者的身份登录，撤销对应用的访问权限，然后重新授权。

Per Zig的答案在下面，就是这样。我有没有办法以编程方式阻止这个非常手动的过程？

来源

2013-04-30 Scott S.

我们能帮忙吗？听起来你知道错误信息的含义，即令牌有问题。听起来像一个调试任务。 – eddyparkinson 2013-04-30 06:49:39

作为所有者执行的脚本将通过appscript内置身份验证自动保存所有者令牌。但是，如果您自己正在执行oauth流程，它将保存用户的令牌，从而无法访问您的数据。

来源

2013-04-30 14:52:26

我在上面添加了更新，有没有办法解决这个问题？ – 2013-05-01 00:55:17

它不清楚你想用保存的令牌访问什么。如果其“所有者”数据在将应用程序提供给用户之前保存刷新令牌。如果它的用户数据，然后每个用户需要做认证流程，你需要为每个用户保存一个令牌。听起来你应该使用appengine。 – 2013-05-02 02:09:21

当'执行应用程序为我'时Google API授权。

更新

回答

相关问题