当您在iOS应用程序和服务器中使用令牌时,如何处理Facebook弃用offline_access

Facebook对offline_access权限的offline_access即将到2012年5月,文档并没有给我们足够的信息如何处理。

我们有一个iOS应用程序和相应的服务,它的function,并与Facebook深入集成,以利用用户的朋友列表内的应用程序(所以如果你的FB朋友也使用应用程序,你可以更容易地连接)。 这就像所有的社交应用程序似乎工作,所以这里没什么特别的。

客户

我们的应用程序使用Facebook iOS SDK来允许用户login,我们当前要求提供offline_access 。 令牌被保存在我们的iOS应用程序,但也发送到我们的服务器保存它的位置。 客户端代表用户行为更新到用户的新闻源(我们也要求publish_stream权限)。

服务器

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

注意:如果用户明确地注销我们的应用程序,我们将从客户端和服务器中删除访问令牌。

问题

现在我们可以使用的不再是一个永久访问令牌,我试图找出最佳实践来继续使用我们的场景,同时利用Facebook新的处理和扩展访问令牌的预期方式。 该文档不幸的是不完全有帮助。

问题

答:当您通过最新的Facebook iOS SDK进行身份validation时,访问令牌的默认生命周期是多less? 这个文件说扩展令牌请求会给你一个持续60天。 这个其他文件谈到了第一个访问令牌请求,并提到了不同的有效性,但还不清楚 ,是否讨论了特定的有效时间:

(重点是我的)

当您从Facebook获取访问令牌时,它将立即生效,并在Facebook定义的一段时间内对API的请求可用。 在这段时间过去之后,访问令牌被视为已过期,用户需要再次进行authentication才能让您的应用程序获得新的访问令牌。 给定访问令牌有效的持续时间取决于它是如何生成的。

还有一些事件可能导致访问令牌在其预期的到期时间之前变得无效。 这些事件包括用户更改密码,应用程序刷新它的应用程序的秘密。 处理不同的访问令牌到期时间,并处理访问令牌在其预期的到期时间之前变得无效的情况对于构build强健的社交体验是必不可less的。

B.对于客户来说,现在访问令牌不一定是长期存在的,对我们来说是正确的做法:

让我们使用通过FBlogin,然后检测访问令牌过期。 如果是,那么调用FB iOS SDK重新authentication/重新授权? (这应该只是触发用户跳出到FB iOS应用程序,并在大多数情况下立即返回到我们的应用程序与一个新的访问令牌)。

C.根据这篇博文我发现,你只能扩展访问令牌一次:

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

不,对不起,你不能。 您只能交换一个有效的(含义当前)用户访问令牌的扩展。 您不能扩展已经扩展的访问令牌。

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

D.每次应用程序启动或重新从睡眠中恢复时,检查FB访问令牌的有效性似乎是有意义的。 我们的iOS应用程序检查这个最好的方法是什么? 是否有build议的端点来调用来validation令牌? 我们是否应该调用https://graph.facebook.com/me传递访问令牌并检查响应?

注意:我们当然可以logging获取最初扩展令牌的expires时间,但这是不可靠的,因为用户可以随时撤销应用程序的许可,从而使expires时间的有效性数据点不可靠

概观

我相信,Facebook试图达到的根本是防止应用程序永久持续访问用户的帐户。 所以,新的迁移应用程序只能访问一个帐户60天,除非用户再次login。

我不为脸书工作,但这里是我玩弄facebook图表API的发现。

通用解决scheme

  1. 每当用户login时,拿取他们的访问令牌,并立即扩展/刷新它,并保存它
  2. logging访问令牌的到期date
  3. 当访问令牌到期(无论是从logging的date,还是一个graphicsAPIexception告诉你),然后通知用户,你没有访问,并要求他们再次login。

答案

答:当您通过最新的Facebook iOS SDK进行身份validation时,访问令牌的默认生命周期是多less? 这个文件说扩展令牌请求会给你一个持续60天。 这个其他文件谈到了第一个访问令牌请求,并提到了不同的有效性,但还不清楚,是否讨论了特定的有效时间:

这是如何工作的:

  1. 第一次login授予您大约两个小时
  2. 通过刷新访问令牌,您可以获得长达60天的时间
  3. 如果用户没有login到这60天,没有办法访问更长的时间没有他们login。
  4. 如果用户取消您的应用授权,那么60天的窗口将立即结束,您将无法再访问。

B.对于客户端来说,现在访问令牌不一定是长期存在的,这对于我们来说是正确的做法:让用户通过FBlogin,然后检测访问令牌何时到期。 如果是,那么调用FB iOS SDK重新authentication/重新授权? (这应该只是触发用户跳出到FB iOS应用程序,并在大多数情况下立即返回到我们的应用程序与一个新的访问令牌)。

如果用户访问令牌已过期,那么唯一的select是让他们通过login循环,就像你正在谈论的那样。

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

您只能扩展访问令牌一次。 在第61天,你运气不好。 最好通知用户,让他们知道,除非他们login,你将无法做任何事情。

D.每次应用程序启动或重新从睡眠中恢复时,检查FB访问令牌的有效性似乎是有意义的。 我们的iOS应用程序检查这个最好的方法是什么? 是否有build议的端点来调用来validation令牌? 我们是否应该调用https://graph.facebook.com/me传递访问令牌并检查响应?

我无法find与debugging控制台相同的API。 这篇FB博客文章讨论了无效的访问令牌,但没有提到任何特别用于testingAPI的API方法。

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

Tid位

  • 当您刷新访问令牌时,将返回一个新的访问令牌。 响应如下所示: access_token=TOKEN&expires=5183912
  • 您只能“刷新”一次访问令牌。 如果您尝试“刷新”从前一个调用返回的长时间标记,它将返回相同的标记,但不会抛出exception,除非令牌已过期。 (换句话说,你可以安全地尝试刷新你的令牌)
  • 默认的访问令牌长度似乎在2个小时左右
  • 如果你“刷新”一个访问令牌,那么这个新的访问令牌似乎是你以后从Facebook API获得的(而不是返回原始的,短暂的访问令牌)

另外,如果你想玩游戏,这些工具可以很容易地在浏览器中testing你的用例,然后把它埋在你的代码中:

  • 图表API浏览器 – 用于创build和获取访问令牌
  • debugging控制台 – 用于检查刷新前/后令牌的到期date
  • 刷新端点 – 用于手动testing扩展令牌

很好的答案,一个重要的补充:默认令牌持续1到2小时。 你得到用户注册的剩余时间,加上1个整小时。 例如,如果用户在下午3:45注册,则访问令牌将在下午5点过期。 为了安全,开发者应该认为它只能持续1小时。