【问题标题】:OAuth + Google + Wordpress pluginOAuth + Google + Wordpress 插件
【发布时间】:2014-11-08 02:22:41
【问题描述】:

背景

我想创建一个最终将安装在“无数”网络服务器上的 PHP 应用程序。 该应用程序将访问与 Web 服务器管理员 Google 帐户关联的 Google Drive(它基本上会在用户的云存储中写入一些文件)。因此,最终用户将授权我的 PHP 应用程序使用其 Google Drive 存储空间。这是通过连接 Google OAuth2 服务来完成的(通过 OAuth2 协议)。

所以基本上我必须创建一个 ClientID/Secret 对(代表我的 Google 帐户),用于执行授权流程。

Google 提供了 3 种授权方式:

  1. 用于网络应用程序(网络上的网络浏览器)
  2. 用于服务帐户(我的服务器到 Google 服务器)
  3. 对于已安装的应用程序(如 Android、iPhone)

(1) 可能是最好的选择,除了我必须定义一个 REDIRECT_URI 来发送授权代码。因为我的 APP 将安装在“无数”不同的服务器上,所以我事先不知道应该返回 Google 响应的协议、域名和路径(也是 URI)。如果我只在 3 台服务器上安装这个应用程序,我可以为每台服务器预先创建一个 ClientID/Secret 对。事实并非如此。

(2) 表示将我的 P12 私钥与 PHP 应用程序一起部署,我对此感到不舒服!

(3) 意味着让最终用户将授权令牌从 Google 网页复制/粘贴到我的应用程序 Web 界面中。我试图避免这样做。

当我事先知道 REDIRECT_URI 时,我已经使用方法 1 使其工作。我还在源代码中嵌入了 client_id/secret 对,因此整个授权过程是用户友好的。但这不适用于“无数”部署场景。

问题

  1. 我应该使用哪种方法以及如何使用它,以确保整个过程对我(作为开发人员)和客户端(Web 服务器管理员)来说都是安全的。请注意,授权过程不应涉及最终用户复制粘贴某些代码。我希望这一步对最终用户来说是透明的/用户友好的(当它可以自动完成时,没有人喜欢复制粘贴)。

  2. 我应该将我的 client_id/secret 嵌入到应用程序中还是完全错误?我想没有最终用户想在 Google Developer Console 中创建自己的 ClientID,对吧?另一方面,为什么我会将我的 client_id/secret 提供给未知的最终用户?

最后的想法

我可以在我的(开发人员)Web 服务器上创建一个代理应用程序,这样我的 PHP 应用程序(应该部署在“任何地方”)将授权请求发送到我的代理服务器(它已经有自己的 client_id/秘密)这反过来会将调用重定向到 Google OAuth 服务,然后 REDIRECT_URI 将授权代码返回给我的代理,最后我会将响应重定向回原始发件人(PHP 应用程序)。你怎么看?

一些有用的答案hereherehere

@Edit:正如我之前已经说过的,代理将是一种解决方案。我已经成功了,它可以工作。我也从用户 pinoyyid 那里收到了相同的解决方案。也谢谢你的回答。

【问题讨论】:

  • 正如 FB OAuth 登录流程所说,“您的应用程序密码永远不应出现在客户端代码中”。这只是加强了我上面的最终想法。

标签: wordpress google-oauth


【解决方案1】:

代理是对您开放的唯一真正选择。您可以在“state”参数中对发起者 URL 进行编码,以便代理在收到访问令牌时,可以在发起者处调用 webhook。

你的问题有些矛盾... “该应用程序将访问与网络服务器管理员 Google 帐户关联的 Google Drive”和“因此最终用户将授权我的 PHP 应用程序使用其 Google Drive 存储空间。”是互斥的。

如果云端硬盘存储属于应用,则用户不会参与任何 OAuth 对话。

您能否编辑您的问题以明确谁是云端硬盘存储的所有者,因为它极大地影响了 OAuth 流程。

【讨论】:

  • 驱动器属于最终用户(又名网络服务器管理员),而不属于应用程序。我看不出这两个陈述是如何自相矛盾的。该应用程序将访问最终用户的驱动器。最终用户必须授权我的应用程序访问其(最终用户)驱动器。基本上,我的应用程序会进行备份。
  • 明白了。我们混合了我们的术语。我猜你正在分发你的网络服务器代码,这就是为什么通常的术语会稍微分解的原因。值得关注的一件事是配额。如果所有用户都共享相同的客户端/项目 ID,他们将使用一个共同的配额。将 client-id 与您的代码分离可能是值得的,这样您就可以拥有一个 id 池并将您的用户分片。
猜你喜欢
  • 2013-05-17
  • 1970-01-01
  • 2021-12-20
  • 2016-02-11
  • 1970-01-01
  • 2011-10-15
  • 1970-01-01
  • 2017-03-04
  • 2021-12-06
相关资源
最近更新 更多