【问题标题】:Google Script OAuth for multiple users适用于多个用户的 Google Script OAuth
【发布时间】:2012-11-23 08:22:01
【问题描述】:

我创建了一个处理 2 个不同 OAuth 连接的 Google 应用脚本。

1- Google 自己代表用户发送邮件并访问 google 文档(用于获取密钥、秘密的 google api 控制台)

2- gtraxapp 是一款基于云的时间表应用程序。 (脚本已注册,获得密钥/秘密等)

脚本作为网络应用程序发布。它非常适合我的用户。

当以不同的用户名登录时,我可以在不提供不同密钥/秘密的情况下授权 Google OAuth,并且电子邮件将从实际用户发送。

第二个应用 (gTrax) 出现问题。 授权似乎有效。在脚本中运行该函数以进行授权会导致屏幕请求权限,然后 gtrax 作为注册应用程序出现在帐户中(如果需要,可以撤销访问权限)。 但是,在运行应用程序时,我收到一条消息说我需要权限才能执行此操作(UrlFetchApp / 简单获取)

我的问题是:

这可能是我需要注册每个用户以获得每个人的密钥/秘密(并在脚本中处理)... 或者 OAuth 可以用 1 个密钥/秘密注册吗?

换句话说,是(应该)链接到单个用户的密钥/秘密,还是它们只是一种类似 RSA 的密钥对,经过验证后,可用于授权任何用户。

【问题讨论】:

  • 我想我遗漏了一些东西。简单 UrlFetchApp 周围的错误消息似乎不合适。您是否将应用程序部署为以您或最终用户身份运行?您是使用 /dev 链接还是 /exec 链接进行测试?这似乎与 oAuth 无关,但可能还有更多。您能否提供有关确切错误消息的更多详细信息(可能是屏幕截图?)
  • 事实上,我离让它工作不远了,我只需要构建一个“非常简单”的函数,使用 fetch 并完成一个 OAuth。从我所见,似乎要使流程正常运行,您必须“完成”交易,而不仅仅是发送信息并允许应用程序。您必须接收数据。然后,您的应用程序将被允许从 Web 应用程序访问。

标签: google-apps-script oauth-2.0


【解决方案1】:

我的理解是这样的。当您使用内置的 Apps 脚本功能(例如 MailApp.sendEmail)时,Google Apps 脚本“环境”会照顾您为用户请求授权(他第一次访问您的应用程序时)并为您保存和管理 oAuth 令牌,所以一切顺利。

当您使用 UrlFetchApp 调用外部服务时,Apps Script oAuth 授权过程的工作方式会有所不同。当您实际拨打fetch 时,授权只是您在脚本编辑器上得到的一个奇怪的弹出窗口。它不会在“编译时”处理,而是在您运行其他服务之前询问。但是您也只执行此步骤一次。 “陷阱”是当用户将应用程序作为 web 应用程序运行时,这种不同的授权过程不起作用。 AFAIK 它仅适用于脚本编辑器本身或直接从电子表格运行。

如果您的用户只是少数已知的用户,您可以建议每个人打开脚本编辑器(或包含它的电子表格)并运行一个特定的函数,该函数将尝试调用 UrlFetchApp.fetch,以便弹出窗口出现并且他们授权它。完成这一步后,他们就可以正常使用webapp了。之后,Apps 脚本将为您施展魔法。

但是,如果您打算在 Chrome 网上应用店进行广泛分享,并且不想要求每个用户都执行这个有点奇怪的步骤,那么您需要自己管理所有授权过程。这意味着,您必须向第三方服务注册您的应用程序(如果是 Google 的,则在 API 控制台),您将在其中收到 client idclient secret。有了这些,您必须在您的应用程序 html 上放置一个“授权”提交按钮,该按钮会将用户重定向到第 3 方授权 url,提供正确的范围等。当他们授权时,第 3 方会将用户重定向回来向您的应用程序提供 code 令牌作为 URL 参数。您将使用此 code 调用第 3 方 oAuth 服务以获取真正的 access 和可能的 refresh 令牌,您必须在您的 UrlFetch 调用中使用这些令牌。您将负责保存这些令牌,在它们过期时刷新它们等等。不是一个非常简单的过程:-/

哦,虽然您的应用只有一个 idsecret,但令牌是每个用户的。这是有道理的,因为您进行的每个呼叫都必须代表特定用户,并且他*必须*已授权。

我希望这会有所帮助。

【讨论】:

  • 感谢您的回答。它引导我进一步调查,我发现我的功能有些问题。为了允许授权,我随后简化了另一个函数,该函数将 1 个获取请求与 OAuth 信息一起使用,并且它起作用了。我希望有一天 Google 会简化 Web App 中的 OAuth 流程...这个应用程序将在内部用于生成 TimeSheet,因此配置每个人都不会太难...但它仍然太复杂了。
  • 是的,Urlfetch oAuth 过程并不像内置服务身份验证那么简单。我很高兴我能帮上忙。顺便说一句,由于您是 StackOverflow 的新手,所以当您觉得自己得到了一个好的答案时,您应该将答案标记为已接受。这是投票箭头附近的复选图标。
猜你喜欢
  • 2018-06-11
  • 2015-11-07
  • 1970-01-01
  • 2021-06-10
  • 1970-01-01
  • 1970-01-01
  • 2015-01-25
  • 2018-04-28
  • 2020-04-27
相关资源
最近更新 更多