Ste*_*lim 6 facebook offline-mode facebook-access-token
在离开FB平台一段时间后我回来建立一个FB应用程序,我发现旧的offline_access权限已被删除并替换为long(ish)-expiry tokens [1].
因此,现在看起来任何需要将数据推送到Facebook的外部应用程序,例如,外部应用程序中的计划或某些活动都需要处理已过期的长访问令牌.这更令人沮丧,因为现在注销FB的用户也将终止任何长期到期令牌[2],而之前,即使用户注销,offline_access仍然存在.
我仍处在思考解决阶段,但有两个想法浮现在脑海中:
1)每当我的应用程序联系具有FB集成的用户时,他们都会被要求单击一个链接,该链接将触发与FB重新授权以获取新的长访问令牌.我的用户通常会在长访问令牌的生命周期内多次联系,因此,只要他们需要,这应该有效地更新长访问令牌(即使它确实给我的应用添加了一些烦人的摩擦)
2)因为我无法保证1)将始终有效(例如,由于用户未点击我的应用程序的电子邮件通知中的重新验证链接或他们退出Facebook,我)还必须处理失败的FB交互将它们放入保留队列并通过电子邮件发送给用户,明确要求他们再次授予长访问令牌.不酷,但我看不到其他选择.如果他们在X尝试要求他们重新授予权限后没有回应请求,我只需要将任务分类并通过电子邮件发送给他们解释这是由于FB限制而不是我的应用程序.再次,不酷.
有没有人必须提出任何更好的解决方案来保持与身份验证/显式权限的用户帐户交互的能力?我很想知道你做了什么.
(这一切都在等待我重读FB ToS,当然 - 这完全有可能违反规则,这将更令人沮丧)
编辑/更新:我需要推送的数据是图像到相册,该相册将从各种来源到达我的服务器,然后被推送到适当的用户专辑中(当然,他们已经获得了预先授予的许可).我无法保证在图像到达我的服务器的时间点进行任何基于Web的最终用户交互,以便让最终用户授予我新的短寿命令牌.基本上,offline_access这对IMO来说真的很理想.
更新2:注意:我的用例非常关键,当需要授予或扩展令牌时,用户不一定会使用我的应用程序或Facebook.
[1] https://developers.facebook.com/roadmap/offline-access-removal/ [2] http://developers.facebook.com/blog/post/2011/05/13/how-to--handle -expired存取令牌/
您有两个正确的选项,但我会指出第三个选项和一个鲜为人知的事实,该事实可能与您的“需要将数据推送到 Facebook”的特定场景相关,也可能不相关
首先,假设您为应用程序实现了移动网络或画布,则另一个可用选项是应用程序到用户请求或通知。用户将在书签列表中您的应用程序名称旁边看到一个小通知计数器指示器。如果他们响应请求或书签/通知计数器让他们点击您的应用程序,您可以触发服务器端令牌续订/扩展过程。这个过程对用户来说是透明的——假设他们仍然安装了你的应用程序,他们什么也看不到。
其次,现在很多人使用offline_access 的目的只是发布到用户的流中。如果这就是您所需要的,并且您不需要执行一堆 FQL 查询或在图形 API 上执行其他操作,那么如果您获得了publish_stream权限,那么您实际上不需要offline_access或当前用户令牌。通过publish_stream,您可以在用户离线时使用您的应用程序访问令牌进行发布。
| 归档时间: |
|
| 查看次数: |
943 次 |
| 最近记录: |