简介
谷歌眼镜、谷歌助手、谷歌云,更不用说谷歌了,谷歌工作空间为谷歌云端硬盘提供了相关服务,如谷歌文档、表格、幻灯片等,就像人们常说的那样——谷歌无处不在。尽管 Google 并非一切都是完美的,这就是他们提供的文档,尽管我注意到他们已经在研究它(也许有人对文档的反馈值得花时间),他们甚至在新的翻新 PWA 系列上发布了实时文档检查出来。虽然我的意图很简单,但我可以说和说:我正在构建将利用一些 GCP 提供的服务 API 的外部应用程序。问题是文档没有明确定义 Installed apps 和 Web Apps 之间的区别。幸运的是,在 GitHub 上打开了一些问题,更不用说在 developer.google 上耐心阅读了数小时,在我看来,平均组织的文档(在撰写本文时),我已经设法揭开了以下神秘面纱:
已安装的应用程序
-
Service-to-Service 使用服务帐户:没有任何最终用户(human like me & you)的预期交互,您构建的应用程序模拟最终用户只维护两方。这种 OAuth 2.0 流程称为 2LO(双腿流程)
-
服务器端在用户帐户中:这是三足 (3LO) OAuth 2.0 流程,它封装了三方,即:a) 最终用户代表客户端同意,b) 客户端(您的应用程序) 与 c) Google 服务代表最终用户同意提供 API。
网络应用程序
- 部署在 Google Cloud 中的 Apps 脚本(JavaScript 应用程序,而您的应用程序分为:a)您机器上的前端和 b)Google Cloud 上的后端,俗话说 - 在 Apps 脚本服务环境中 [请参阅此热点.js 作为实际示例])
注意:您的 Web 应用程序 可能需要使用 3LO 授权(流)。在这种情况下,您需要将默认 GCP 项目切换到标准项目,明确将指定的项目 ID 定位到 Apps 脚本代码库(步骤 2-4 遵循)。
提示:在进行任何开发操作之前切换是一种很好的做法,因为稍后切换到标准进行开发可能会有 - “副作用]”。
最后 : 还有很多其他原因要切换(阅读列表)
回顾
默认为 Standard ,包括是否使用 service-account 可能会令人生畏,这就是我制作这张表来总结上面所说的一切:
默认
对比
标准
2LO 使用用户帐户(例如带有*out* 同意屏幕的 Web 应用程序)
...
3LO 与用户帐户(例如,服务器端作为带有同意屏幕的 Web 应用程序)
...
...
带有服务帐户的 2LO(例如,带有*out* 同意屏幕的服务到服务)
尾注
您可能会猜到我已经有了一些 Web Apps 的基本经验,答案是正确的,我有!当谈到NOT Web 应用程序时,比如说将被其他最终用户利用的服务器端应用程序(例如,开发人员为某些公司构建应用程序),这不是一种应用程序(客户端)我我个人建立,而不是那样,使用服务帐户的服务到服务是一种方法!服务帐户可帮助您避免最终用户(人)参与,这意味着您不需要配置任何同意屏幕——这基本上是 2LO 流程的全部内容——服务帐户自行模拟最终用户(管理自己的数据而不是最终用户的),仅导致两方参与,即:您构建的应用程序(客户端)和 Google 的服务帐户作为受保护资源的身份。
如果您担心..:
请支持我在 Drive API for Node.js 上发布的错误
参考
-
*旧版(旧版)
-
**现在(更新)
注意 : *目前正在试验旧版,因为它提供了更大的 GCP 服务支持 API 列表
如果有什么要补充的,请在下方评论区留言。谢谢,下一篇再见!