Facebook Graph API:有app访问令牌,需要用户访问令牌而无需交互

我们有一个音频博客网站,可以配置为在用户创建新博客条目时发布指向用户Facebook时间线的链接。

为此,我们让用户在设置Facebook帐户链接时授权我们的应用程序。 我们获取了publish_streamoffline_accessmanage_pages权限(稍后会详细介绍)。

所有代码都在C#中,但这些原则适用于任何语言,因为它是我们关注的Facebook API的工作方式。 我们正在使用OAuth 2Graph API来实现所有这些目标。

因此,我们使用我们的应用程序ID密码获取应用程序访问令牌 ,并使用该令牌发布到用户的时间轴,这很好(因为他们已经授权我们的应用程序执行此操作)。 我们还可以查询Graph API并获取他们的喜欢朋友和各种其他数据。

现在这是问题:

我们的一些用户希望将更新发布到他们自己的时间戳以及他们管理的页面的时间轴。 从理论上讲,这很简单:使用此URL查询用户管理的页面的API: https : //graph.facebook.com/{userid}/ accounts ? access_token = {token}

据说,从此调用返回的JSON包含页面ID和这些页面的页面访问令牌。 然后,您可以使用页面访问令牌发布到页面的时间轴。

但是,当我们尝试使用app访问令牌调用此URL时,我们会收到OAuthException 102 “请求此资源需要用户访问令牌”。

请注意,这与OAuthException 104 “请求此资源需要访问令牌”(如果您忽略传递访问令牌,这是您将获得的)以及OAuthException 190 “无效的OAuth访问令牌签名”(您如果访问令牌不是有效的,则会获得)。

因此,我们的访问令牌有效,但对此特定url无效。 因此,我们似乎需要一个用户访问令牌,而不是这个特定订阅源的应用访问令牌 (我很久以前一直在关心为什么会这样,它似乎就是这样)。

关于这个主题的所有Facebook文档(我现在必须阅读所有这些文档)导致一个地方: http : //developers.facebook.com/docs/authentication/server-side/ ,又名“服务器端认证”流程“页面。 此页面描述了如何通过将用户重定向到auth对话框并询问相关权限来获取难以捉摸的用户访问令牌, 但我们需要在没有用户交互的情况下实现此目的,并且用户已经为我们的应用程序提供了所需的所有权限 。 所有这些自动发布都在音频的后处理中发生在服务器端,因此我们无论如何都无法在此阶段与用户进行交互。

我不明白。 为什么我们可以使用应用访问令牌来获取我们想要的任何数据(好吧,无论他们给予我们什么许可),但/ accounts数据我们需要一个不同的(用户)访问令牌?

任何人都可以了解我们如何获得用户访问令牌,这将允许我们为用户获取/ accounts数据而无需用户进行任何进一步的交互?

因此,我们的访问令牌有效,但对此特定url无效。 因此,我们似乎需要一个用户访问令牌而不是此特定Feed的应用访问令牌

由于每种类型的访问令牌的权限,在这种特定情况下您需要有效的用户访问令牌。 阅读有关访问令牌和类型的所有信息 。 就是那样子。

此页面描述了如何通过将用户重定向到auth对话框并询问相关权限来获取难以捉摸的用户访问令牌, 但我们需要在没有用户交互的情况下实现此目的,并且用户已经为我们的应用程序提供了所需的所有权限

如果您的用户已经授予他/她的权限,那么您为什么要挣扎呢? 我建议你坚持用户访问令牌。 从这个端点 :

https://www.facebook.com/dialog/oauth?client_id=..&redirect_uri=..&state=..&scope=..&response_type=..&display=.." 

你检索一个代码,像这样:

 YOUR_REDIRECT_URI?code=OAUTH_CODE_GENERATED_BY_FACEBOOK&state=YOUR_STATE_VALUE 

使用此代码生成用户访问令牌,如下所述:

 https://graph.facebook.com/oauth/access_token?client_id=..&redirect_uri=..&client_secret=..&code=.. 

这将导致如下响应:

 access_token=USER_ACCESS_TOKEN&expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES 

它就是您的用户访问令牌。 坚持下去。 如您所见,它在响应中指示的值之后到期。 如果您正在使用新的API,它应该指示60天(这让我回到这一点:不推荐使用offline_access,结果是短暂的 – 有效期为2小时 – 令牌), 链接 。 每当您的用户登录到您的应用并使用Facebook集成时,令牌会再次刷新60天。 这意味着,如果您的用户不应该登录您的应用并使用它60天,它将会过期。

您可以检查用户访问令牌是否已过期:

 https://graph.facebook.com/debug_token?input_token=INPUT_TOKEN&access_token=ACCESS_TOKEN 

如果是这样的话: 使用您的应用访问令牌续订用户访问令牌 ,就可以在此处详细记录 。 但我引用这部分:

服务器端登录在这种情况下,要获得全新的[用户]访问令牌,您必须再次通过用户完整的服务器端登录流程。 但是,假设用户未取消您的应用程序的授权,当您将用户重定向到OAuth对话框时,系统不会提示他们重新授权您的应用,并且会立即将其重定向到redirect_uri。 这意味着重新认证过程对用户来说可以显得相当透明。

底线:没有用户访问权限永久有效,但应用访问令牌却是。 在使用它执行API调用之前,请保留您的用户访问令牌并检查它是否仍然有效。 普通用户应该在60天内使用您的应用程序,而不应仅仅取消授权您的应用程序以获得乐趣。 因此,用户应该重新授权的用例是相当罕见的,但是,您需要期望它。