Facebook的offline_access权限的deprecation即将于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定义。在该时间段过去之后，访问令牌 被认为已过期且用户需要 再次进行身份验证，以便您的应用获得全新访问权限 令牌。 给定访问令牌有效的持续时间取决于 它是如何生成的。
还有可能导致访问令牌变为的事件 在预期到期时间之前无效。这些事件包括用户 更改密码，一个应用程序刷新它的App Secret。 处理不同的访问令牌到期时间，并处理案例 当访问令牌在其预期到期时间之前变为无效时 对于建立强大的社交体验至关重要。
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时间变得不可靠数据点的有效性
答案 0 :(得分：16)
<强>概述
我认为facebook试图实现的目的是阻止应用永久访问用户的帐户。因此，通过新迁移，应用只能访问帐户60天，除非用户再次登录。
我不为facebook工作，但这是我在玩facebook图表api时的调查结果。
常规解决方案
<强>答案
一个。通过最新的Facebook iOS SDK进行身份验证时，您获得的访问令牌的默认生命周期是多少？该文档说扩展令牌请求将为您提供持续60天的令牌请求。这个其他文档讨论了第一个访问令牌请求，并提到了不同的有效性，但它不清楚，是否谈论具体的有效时间：
以下是它的工作原理：
B中。对于客户端，现在访问令牌不一定是长期存在的，对我们来说是正确的方法：让我们使用FB登录，然后检测访问令牌何时到期。如果是，那么调用FB iOS SDK重新认证/重新授权？ （这应该只是触发用户弹出到FB iOS应用程序，并且在大多数情况下会立即使用新的访问令牌返回我们的应用程序。）
如果用户访问令牌已过期，您唯一的选择就是让他们像您所说的那样经历一个登录循环。
℃。根据我发现的这篇博文，你只能扩展一次访问令牌。在客户端，我可以通过提示重新认证/重新授权来解决这个问题，正如我在问题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中所推荐的。事实上，我可能会在我的应用程序中使用这种方法作为检查访问令牌的主动方式。
Tid Bits
access_token=TOKEN&expires=5183912 此外，如果您想玩游戏，这些工具可以让您轻松地在浏览器中测试用例，然后再将其嵌入代码中：
答案 1 :(得分：0)
很棒的答案，一个重要的补充：默认令牌持续1到2个小时。您将获得用户注册的剩余时间，加上1小时。例如，如果用户在下午3:45注册，则访问令牌将在下午5点到期。为了安全起见，开发人员应该假设它只持续1小时。