当您在 iOS 应用程序和服务器中都使用令牌时如何处理 Facebook 弃用的离线访问权限

Posted 2023-03-31

【中文标题】当您在 iOS 应用程序和服务器中都使用令牌时如何处理 Facebook 弃用的离线访问权限

【英文标题】：How to handle Facebook's deprecation of offline_access when you use token both in both iOS app and a server

【发布时间】：2012-04-12 22:09:29

【问题描述】：

Facebook 的 deprecation 和 offline_access 权限将于 2012 年 5 月推出，但文档没有为我们提供有关如何处理它的足够信息。

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

客户

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

服务器

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

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

问题

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

问题

A.当您通过最新的 Facebook iOS SDK 进行身份验证时，您获得的访问令牌的默认生命周期是多少？ This document 表示扩展令牌请求将为您提供一个持续 60 天的令牌。这个other document 谈到了第一个访问令牌请求并提到了不同的有效性，但它是unclear 并谈到了具体的有效性时间：

（重点是我的）

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

还有一些事件可能导致访问令牌变为 在其预期到期时间之前无效。此类事件包括用户 更改他们的密码，一个应用程序刷新它的应用程序秘密。 处理不同的访问令牌到期时间，并处理案例 当访问令牌在其预期到期时间之前变得无效时 对于建立强大的社交体验至关重要。

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

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

C. 根据我发现的this blog post，您只能扩展一次访问令牌：

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

不，抱歉，您不能。您只能交换有效（即当前） 扩展的用户访问令牌。你不能扩展一个已经 扩展访问令牌。

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

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

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

【问题讨论】：

我也在寻找 B 的答案。目前 FB 正在给我在 iOS 上持续 2 小时的访问令牌。这是否也意味着我应该停止尝试让 [Facebook extendAccessToken] 和 [Facebook extendAccessTokenIfNeeded] 工作，因为它们现在已经不存在了？

@TMC 不是定期为添加该应用程序的朋友“轮询”，您是否可以在获得新用户时“推送”该数据？如果这是您唯一使用的离线访问令牌，那么它可能是实现新的 offline_access 东西的替代解决方法。

@logan：我们的服务器会定期轮询 FB 以检查好友列表的变化，并监控我们的系统以查看您的好友是否已注册。然后，我们在朋友之间进行一些自动关注，以使应用程序更具吸引力。我看不出推送数据是如何工作的。

我在原始问题中添加了第四个问题 D。

@TMC 对不起，你是对的。如果有两个人在朋友之前使用您的应用，那么您必须进行投票。

【参考方案1】：

概述

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

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

一般解决方案

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

答案

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

它是这样工作的：

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

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

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

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

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

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

我找不到与 Debug Console 等效的 API。 This FB blog article 谈到了无效的访问令牌，但没有提到任何专门用于测试 API 的 API 方法。

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

花絮

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

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

Graph API Explorer - 用于创建和获取访问令牌 Debug Console - 用于在刷新之前/之后检查令牌的到期日期 Refresh Endpoint - 用于手动测试扩展令牌

【讨论】：

您也可以通过推送通知让用户知道他们需要重新登录。这可能会让您更快地回复/登录，因为不是很多人经常查看电子邮件。

你的意思是app-to-user requests？它们也可能有用。

不，我的意思是服务器可以向客户端发送推送通知，以便提示用户再次打开应用程序并登录。我不知道应用程序对用户的请求是什么.现在阅读它。

好点。推送通知不适用于我的 Web 应用程序，但我已经更新了答案并将通知用户部分留给了开发人员。

它仍然显示为电子邮件，但无论如何，+1 表示良好、详细的答案。

【参考方案2】：

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