11

Facebook将在 2012 年 5 月弃用该offline_access许可，并且文档没有为我们提供有关如何处理它的足够信息。

我们有一个 iOS 应用程序和相应的服务，为其提供支持并与 Facebook 深度集成，以在应用程序内利用用户的朋友列表（因此，如果您的 FB 朋友也在使用该应用程序，您可以更轻松地建立联系）。这就像所有社交应用程序的工作方式一样，所以这里没什么特别的。

客户

我们的应用程序使用Facebook iOS SDK来允许用户登录，这是我们目前要求的offline_access。令牌保留在我们的 iOS 应用程序中，但也会发送到保存它的服务器。客户端代表用户向用户的新闻源发布更新（我们也请求publish_stream许可）。

服务器

我们的服务器会定期检查用户的 FB 好友是否正在使用我们的应用程序。下次用户登录时，我们会以某种方式公开内容和关系以宣传该用户的朋友。服务器还代表用户定期连接到图 API 并获取用户的当前好友列表。这样我们就可以解释用户关系的变化，并将它们反映在我们的应用程序中。当用户当前未使用该应用程序时，我们会执行此操作，以便他们在下次使用该应用程序时获得最佳体验。为了实现这一点，我们的 iOS 应用程序将访问令牌发送到它使用的服务器以及我们请求的原因offline_access。

注意：如果用户明确退出我们的应用程序，我们会从客户端和服务器中删除访问令牌。

问题

既然不再有我们可以使用的永久访问令牌，我正在尝试找出在利用 facebook 处理和扩展访问令牌的新预期方式的同时仍然启用我们的场景的最佳实践。不幸的是，文档并不完全有帮助。

问题

A.当您通过最新的 Facebook iOS SDK 进行身份验证时，您获得的访问令牌的默认生命周期是多少？这份文件说，一个扩展的令牌请求会给你一个持续 60 天的令牌。另一个文档讨论了第一个访问令牌请求并提到了不同的有效性，但不清楚，它是否讨论了具体的有效性时间：

（重点是我的）

当您从 Facebook 获得访问令牌时，它将立即生效，并可在 Facebook 定义的一段时间内用于对 API 的请求。这段时间过去后，访问令牌被视为已过期，用户将需要再次进行身份验证，以便您的应用程序获得新的访问令牌。给定访问令牌的有效期取决于它的生成方式。

还有一些事件可能导致访问令牌在其预期到期时间之前变得无效。此类事件包括用户更改密码、应用程序刷新其 App Secret。处理不同的访问令牌到期时间，以及处理访问令牌在其预期到期时间之前失效的情况对于构建强大的社交体验至关重要。

B.对于客户来说，既然访问令牌不一定是长期存在的，那么我们的正确方法是：

让我们通过 FB 使用登录，然后检测访问令牌何时过期。如果是，那么调用FB iOS SDK重新认证/重新授权？（这应该只会触发用户跳出到 FB iOS 应用程序，并且在大多数情况下会立即使用新的访问令牌返回我们的应用程序）。

C.根据我发现的这篇博文，您只能扩展一次访问令牌：

我可以将我的 60 天访问令牌换成新的 60 天访问令牌吗？

不，对不起，你不能。您只能将有效（即当前）用户访问令牌交换为扩展令牌。您不能扩展已扩展的访问令牌。

在客户端，我可以通过提示重新认证/重新授权来处理这个问题，正如我在问题 B 中提到的那样。但是，这在我们的服务器上不起作用。我们当然可以让服务器将它更新一次到 60 天，但是在第 61 天会发生什么？服务器只是停止能够同步朋友的列表？

D.每次应用程序启动或从睡眠状态恢复时检查 FB 访问令牌的有效性似乎是有意义的。我们的 iOS 应用程序检查这一点的最佳方法是什么？是否有推荐的端点来调用以验证令牌？我们是否应该调用https://graph.facebook.com/me传递访问令牌并检查响应？

注意：我们当然可以记录expires我们获得初始扩展令牌的时间，但这并不可靠，因为用户可以随时撤销我们应用程序的权限，这使得expires时间成为不可靠的有效性数据点

4

2 回答 2

16

概述

我相信 facebook 试图实现的根本目的是防止应用程序永久永久访问用户帐户。因此，在新的迁移中，除非用户再次登录，否则应用只能访问一个帐户 60 天。

我不为 facebook 工作，但这是我在玩 facebook graph api 时的发现。

通用解决方案

  1. 每当用户登录时，获取他们的访问令牌并立即扩展/刷新它并保存它
  2. 记录访问令牌的到期日期
  3. 当访问令牌过期时（从记录日期或图形 API 异常告诉您），然后通知用户您没有访问权限，并要求他们再次登录。

答案

A. 当您通过最新的 Facebook iOS SDK 进行身份验证时，您获得的访问令牌的默认生命周期是多少？这份文件说，一个扩展的令牌请求会给你一个持续 60 天的令牌。另一个文档讨论了第一个访问令牌请求并提到了不同的有效性，但不清楚，它是否讨论了具体的有效性时间：

以下是它的工作原理：

  1. 首次登录为您提供大约两个小时的时间
  2. 通过刷新访问令牌，您最多可以获得 60 天
  3. 如果用户在这 60 天内未登录，则在不让他们登录的情况下无法获得更长时间的访问权限。
  4. 如果用户取消对您的应用程序的授权，则 60 天的窗口会立即结束，您将无法再访问。

B. 对于客户端，既然访问令牌不一定是长期存在的，那么我们的正确做法是：让我们通过 FB 登录，然后检测访问令牌何时过期。如果是，那么调用FB iOS SDK重新认证/重新授权？（这应该只会触发用户跳出到 FB iOS 应用程序，并且在大多数情况下会立即使用新的访问令牌返回我们的应用程序）。

如果用户访问令牌已过期，您唯一的选择是让他们像您所说的那样通过登录循环。

C. 根据我发现的这篇博文，您只能扩展一次访问令牌。在客户端，我可以通过提示重新认证/重新授权来处理这个问题，正如我在问题 B 中提到的那样。但是，这在我们的服务器上不起作用。我们当然可以让服务器将它更新一次到 60 天，但是在第 61 天会发生什么？服务器只是停止能够同步朋友的列表？

您只能扩展一次访问令牌。第 61 天，你运气不好。最好通知用户并让他们知道，除非他们登录，否则您将无法执行任何操作。

D. 每次应用程序启动或从睡眠状态恢复时检查 FB 访问令牌的有效性似乎是有意义的。我们的 iOS 应用程序检查这一点的最佳方法是什么？是否有推荐的端点来调用以验证令牌？我们是否应该调用https://graph.facebook.com/me传递访问令牌并检查响应？

我找不到与Debug Console等效的 API 。这篇 FB 博客文章讨论了无效的访问令牌，但没有提及任何专门用于测试 API 的 API 方法。

我你的击球建议https://graph.facebook.com/me 会很好，这正是他们在他们的例子中推荐的。事实上，我可能会在我的应用程序中使用这种方法作为检查访问令牌的主动方式。

花絮

  • 当您“刷新”访问令牌时，将返回一个新的访问令牌。响应如下所示：access_token=TOKEN&expires=5183912
  • 您只能“刷新”一次访问令牌。如果您尝试“刷新”从先前调用返回的长期存在的令牌，它将返回相同的令牌，但除非令牌已过期，否则不会引发异常。（换句话说，您可以安全地尝试刷新您的令牌）
  • 默认访问令牌长度似乎约为 2 小时
  • 如果您“刷新”访问令牌，则新的访问令牌似乎是您之后将从 facebook API 获得的访问令牌（而不是返回原始的、短暂的访问令牌）

此外，如果您想尝试一下，这些工具可以让您轻松地在浏览器中测试您的用例，然后再将其埋入您的代码中：

于 2012-04-15T00:15:03.330 回答
0

很好的答案，一个重要的补充：默认令牌持续 1 到 2 小时。您将获得用户注册的剩余时间，再加上 1 个完整小时。例如，如果用户在下午 3:45 注册，则访问令牌将在下午 5 点过期。为了安全起见，开发人员应该假设它只持续 1 小时。

于 2012-04-30T17:53:10.813 回答