1

我正在开发一种同时具有桌面网站和本机 iOS 应用程序的产品。我们在两种情况下都为我们的用户提供 Facebook 连接作为登录选项。

我的目的是通过安全的 JSON API 共享相同的 Facebook 令牌，以便在两种情况下使用：当用户登录网络时，令牌存储到我们的后端，以便移动客户端下次运行时，它可以下载令牌并使用它，反之亦然。（*我在问题末尾解释了这种方法的详细推理，对于问题不是必需的。）

问题：当iOS客户端使用token预设一个feed dialog时，如果该token是web使用server-side flow生成的，dialog webview会呈现错误：

“{我的应用名称}出现错误。请稍后再试。”

这是可靠的可重现的：

  1. 使用服务器端流程生成新的访问令牌。确保您请求 publish_actions 权限，因为您将使用提要对话框。
  2. 使用隐身浏览器窗口（获取一个空的 cookie 罐），查看 iOS 提要对话框将在其 web 视图中呈现的 m.facebook.com 页面：https ://m.facebook.com/dialog/feed?access_token=SERVER_SIDE_FLOW_ACCESS_TOKEN&app_id =YOUR_APP_ID&redirect_uri=fbconnect%3A%2F%2Fsuccess&sdk=2&display=touch

除了#2，您可以完成所有工作（我已经完成）使用 Facebook SDK 创建一个虚拟 iOS 应用程序，正确实例化它并显示对话框。为了重现错误，直接访问 m.facebook.com 提要 URL 更容易。

如果令牌是由本机 Facebook iOS SDK 发起的身份验证流而不是服务器端身份验证流生成的，则上述提要 URL 可以正常工作，正如预期的那样。

此外，任何一个令牌（移动或服务器生成）都非常适合直接通过图形 api 发布提要项目。问题实际上只是与移动提要对话框有关。

Facebook 是否故意禁止服务器端生成的令牌在移动提要对话上下文中运行？

这是 m.facebook.com 上的提要对话框端点的错误吗？

或者，希望，我做错了什么？

为什么我要分享代币？

  • 由于正在删除 offline_access 权限，因此每个客户端（Web 与移动）都可以从让另一个客户端在用户处于活动状态时刷新相同的令牌中受益。这将导致令牌过期的情况减少，因此用户必须从头开始重新进行身份验证的情况也将减少。
  • 同样，不会频繁地要求用户批准额外的权限，因为每个客户端都可以从对方的权限增强中受益。
4

1 回答 1

3

您从服务器端身份验证获得的令牌与客户端的令牌不同（我将 iOS/Android 视为客户端）。服务器令牌的寿命很长（60 天），而客户端令牌的寿命很短（几个小时）。

服务器端流程增加了另一层安全性，您的服务器对 facebook 服务器进行身份验证，这可能是您在使用此流程时自动获得长期令牌的原因。

如果您使用访问令牌尝试调试器，您将收到有关令牌的信息，例如令牌的“来源”。例如，从客户端身份验证（使用 js）生成的令牌具有“Origin：Web”。这意味着 facebook 确实区分了令牌。

我不是 100% 确定这一点，但从你所说的听起来确实像 facebook 将 UI 限制为客户端令牌的使用而不是服务器端令牌，可能是因为对话框让用户不需要做事应用程序获取权限，因此如果您有 60 天令牌，则您的应用程序可以代替用户使用它，并在未经他许可的情况下代表他做事。我只是在这里猜测。

我建议你只在服务器端使用服务器令牌，让 iOS 客户端处理他自己的令牌。根据处理无效和过期的访问令牌指南，它指出：

iOS 原生应用

API 错误由 FBRequestDelegate 接口处理。当您检测到访问令牌无效或已过期时，您的应用程序将需要将多任务转移到 Facebook iOS 应用程序。假设用户没有取消对您的应用程序的授权，他们将立即使用新的有效访问令牌将多任务返回到您的 iOS 应用程序。

这意味着您不必担心令牌在客户端过期。

于 2012-05-10T08:30:03.000 回答