Facebook的offline_access
许可权的deprecation将于2012年5月发布,该文档并未向我们提供有关如何处理它的足够信息。
我们拥有一个iOS应用程序以及与之配套的相应服务,并与Facebook进行了深度集成,以利用外部应用程序中的用户好友列表(因此,如果您的FB friend 也正在使用该应用程序,则可以更轻松地进行连接)。就像所有社交应用似乎都在工作一样,因此这里没有什么特别的。
客户
我们的应用程序使用Facebook iOS SDK允许用户登录,目前我们要求offline_access
。 token 会保留在我们的iOS应用中,但也会发送到我们的服务器中进行保存。客户端代表用户行事,将更新发布到用户的新闻源(我们也要求publish_stream
许可)。
服务器
我们的服务器会定期检查用户的FB friend 是否正在使用我们的应用程序。下次用户登录时,我们将以某种方式公开内容和关系,以提升该用户的 friend 。服务器还代表用户执行操作,以定期连接到图形API并获取用户的当前 friend 列表。这样一来,我们就可以考虑用户关系中的更改并将其反射(reflect)在我们的应用程序中。我们在用户当前不使用该应用程序时执行此操作,以便他们下次使用该应用程序时获得最佳体验。为此,我们的iOS应用将访问 token 发送到它使用的服务器以及为什么我们要求offline_access
。
注意:如果用户明确退出应用程序,我们将从客户端和服务器上删除访问 token 。
问题
既然不再有我们可以使用的永久访问 token ,我正在尝试找到最佳实践,以便在利用Facebook的新预期方式来处理和扩展访问 token 的同时,仍然启用我们的方案。不幸的是,该文档并不完全有用。
问题
A. 当您通过最新的Facebook iOS SDK进行身份验证时,获得的访问 token 的默认生存期是多少? This document说,扩展的 token 请求将为您提供一个持续60天的请求。这个other document讨论了第一个访问 token 请求,并提到了不同的有效性,但是它是unclear并讨论了特定的有效性时间:
(重点是我的)
B. 对于客户端来说,既然访问 token 不一定要长期存在,那么对于我们而言,正确的方法是:
让我们通过FB使用登录,然后检测访问 token 何时过期。如果是,则调用FB iOS SDK重新认证/重新授权? (这只会触发用户跳回FB iOS应用,在大多数情况下,会使用新的访问 token 立即返回我们的应用)。
C. 根据我发现的this blog post,您只能扩展一次访问 token :
在客户端上,我可以通过提示我在问题B中提到的重新认证/重新授权来进行处理。但是,这在我们的服务器上不起作用。我们当然可以让服务器将其续订一次至60天,但是在第61天会发生什么呢?服务器只是停止能够同步 friend 的名单?
D. 似乎有必要在每次应用启动或从 sleep 中补充水分时检查FB访问 token 的有效性。我们的iOS应用检查此内容的最佳方法是什么?是否有推荐的端点可调用以验证 token ?我们是否应该仅通过传递访问 token 并检查响应来调用https://graph.facebook.com/me
?
注意:当我们获得最初扩展的 token 时,我们当然可以记录expires
时间,但这是不可靠的,因为用户可以随时撤消我们应用程序的许可,这使得expires
时间成为不可靠的数据点
最佳答案
概述
我认为,facebook试图实现的根本目的是防止应用程序永久永久访问用户的帐户。因此,通过新迁移,除非用户再次登录,否则应用程序只能访问60天的帐户。
我不为facebook工作,但是这是我通过使用facebook graph api获得的发现。
一般解决方案
答案
运作方式如下:
如果用户访问 token 已过期,那么您唯一的选择就是让他们像您所说的那样通过登录循环。
您只能扩展一次访问 token 。在第61天,您不走运。最好通知用户,并让他们知道,除非他们登录,否则您将无能为力。
我找不到与Debug Console等效的API。 This FB blog article讨论了无效的访问 token ,但未提及任何特别旨在测试API的API方法。
我建议您点击
https://graph.facebook.com/me
会很好,这正是他们在their example中推荐的建议。实际上,我可能会在我的应用程序中使用这种方法作为检查访问 token 的主动方式。潮汐位
access_token=TOKEN&expires=5183912
同样,如果您想玩转,可以使用这些工具在将其埋入代码之前轻松地在浏览器中测试您的用例: