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

Question

Facebook 对该许可的弃用offline_access即将于2012年5月发布,而且该文档并未向我们提供有关如何处理它的足够信息.

我们有一个iOS应用程序和相应的服务,为它提供支持并与Facebook集成,以便在应用程序内利用用户的朋友列表(因此,如果您的FB朋友也使用该应用程序,您可以更轻松地连接).这就像所有社交应用程序似乎都有效,所以这里没什么特别的.

客户

我们的应用程序使用Facebook iOS SDK允许用户登录,我们目前要求offline_access.令牌会保留在我们的iOS应用程序中,但也会发送到保存它的服务器.客户端代表用户发布更新到用户的新闻源(我们也要求获得publish_stream许可).

服务器

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

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

问题

现在我们不再使用永久访问令牌,我正在尝试找出仍然启用我们的场景的最佳实践,同时利用Facebook新的处理和扩展访问令牌的新方法.遗憾的是,该文档并不完全有用.

问题

答:当您通过最新的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时间成为不可靠的有效数据点

Answer 1

概观

我认为,facebook试图实现的目的是防止应用程序永久持久访问用户的帐户.因此,通过新迁移,应用只能访问帐户60天,除非用户再次登录.

我不是为Facebook工作,但这是我用facebook图api玩的调查结果.

一般解决方案

1. 每当用户登录时,请使用其访问令牌并立即对其进行扩展/刷新,然后保存
2. 记录访问令牌的到期日期
3. 当访问令牌到期时(从记录的日期或图形API异常告诉您),然后通知用户您没有访问权限,并要求他们再次登录.

答案

答:当您通过最新的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传递访问令牌并检查响应吗？

我无法找到与调试控制台等效的API .这篇FB博客文章讨论了无效的访问令牌,但未提及任何特别用于测试API的API方法.

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

Tid Bits

• 当您"刷新"访问令牌时,将返回新的访问令牌.响应如下:access_token=TOKEN&expires=5183912
• 您只能"刷新"一次访问令牌.如果您尝试"刷新"从前一次调用返回的长期令牌,它将返回相同的令牌,但除非令牌已过期,否则不会抛出异常.(换句话说,您可以安全地尝试刷新令牌)
• 默认访问令牌长度似乎约为2小时
• 如果您"刷新"访问令牌,那么新的访问令牌似乎是您之后从facebook API获得的那个(而不是返回原始的,短期访问令牌)

此外,如果您想玩游戏,这些工具可以在将代码嵌入您的代码之前轻松地在浏览器中测试您的用例:

• 图谱API资源管理器 - 用于创建和获取访问令牌
• 调试控制台 - 用于在刷新之前/之后检查令牌的到期日期
• 刷新端点 - 用于手动测试扩展令牌