redirect_uri阻止使基于Intranet的应用程序的能力

Question

我正在开发一个基于Intranet的应用程序，我所工作的公司将会出售该应用程序，它可以作为后台流程的一部分发布到Facebook墙上。

要进行授权，我需要完成流程（即https://graph.facebook.com/oauth/authorize参数client_id=1234567890和redirect_uri=http://customer-intranet.example.com） - 这是第二个阻碍我的，因为我无法预测redirect_uri，Facebook似乎对应用程序中预先指定的整个内容严格要求。

我想我需要设置一个托管网站，从Facebook接收访问令牌，然后以某种方式将该令牌重定向回客户的内部网站，在那里可以使用它。 （然后是整个离线访问令牌弃用的事情......）

我为自己制造的东西太难了吗？有一个更好的方法吗？我查看了其他身份验证流程，其中，设备可能工作，但它显然处于封闭测试阶段。

Answer 1

您可以考虑使用Client Side authentication流程或JS-SDK使用OAuth Dialog，这样您就可以轻松避免指定redirect_uri，因为它可能由JS-SDK自动提供（或您可以使用当前URL window.location，如客户端身份验证流程的文档中所示。

备注：

虽然这可以帮助您避免使用redirect_uri实际问题更深一点......

redirect_uri的使用会使这种流程难以实施，不仅因为无法预测，而且由于要求redirect_uri应位于 App Domain 中，同样适用于JS-SDK。

因此，一般情况下，您需要在应用程序设置中放置redirect_uri / URL应用程序运行的域名，这在许多客户端/域名中都是令人讨厌的。

您可以通过使用单独的（可公开访问的）主机来实现身份验证流程，但在执行此操作之前，最好先问自己几个问题：

1. 谁将对该主机负责，如果该主机出现问题，所有客户将会遇到什么情况。
   • 这是额外的依赖，最好避免。
2. 您是否愿意在应用程序设置中为所有客户提供域名？
   • 这可能导致违反有关向第三方传输数据的平台政策（在此之前咨询公司律师）
3. 您是否需要为所有客户使用单一应用程序？
   • 如果不是，您最好指示客户设置应用程序并使用他们获得的凭据配置您的应用程序/代码。

总结一下：
您可以为每个客户端创建单独的应用程序，或指示客户端将应用程序设置为应用程序的安装/设置过程的一部分。稍后您可以使用客户端身份验证流程来创建适用于每个客户端的通用代码（这也适用于服务器端流程，但需要一些额外的工作，并且使用JS-SDK FB.login它可能是一个丢弃 - 在功能上没有任何额外的工作）。