【问题标题】:Long-lasting FB access-token for server to pull FB page info用于服务器拉取 FB 页面信息的持久 FB 访问令牌
【发布时间】:2012-08-23 12:05:13
【问题描述】:

我知道有很多关于 Facebook 访问令牌及其造成的痛苦的问题,但尽管进行了大量实验并阅读了许多令人沮丧的模糊博客文章(FB 和其他),但我仍在努力获得明确的答案我的需要。让我简要地分解一下到目前为止的过程:

  • 我正在创建一个站点,该站点在服务器端需要从单个 Facebook 页面中提取帖子/状态
  • 我是该 Facebook 页面的管理员
  • 我创建了一个 Facebook 应用
  • 使用Facebook Graph API Explorer,我生成了一个短期密钥,连接到我的应用程序和我的帐户,它授予我的帐户查看我页面的访问令牌的权限
  • 我已将我的短期密钥从this 转换为长期密钥(60 天)ala 场景 4

这就是我卡住的地方。我的 60 天密钥适用于我的服务器从页面中提取所需的信息,但据我所知,没有办法以编程方式扩展该 60 天密钥。我也不知道如何在不手动转到 Facebook Graph API Explorer 并创建一个新的短期密钥的情况下生成一个新的短期密钥。

由于是我的服务器向 Facebook API 发出请求,而不是基于用户的系统(我可以轻松地请求用户再次授权 Facebook 应用程序),这会创建一个非常笨重的系统。由于 Facebook 弃用了offline_access,真的没有永久的方法可以让我的服务器从我自己的页面中提取信息吗?我真的需要每 60 天手动创建一个新密钥并使用它手动更新我的服务器吗?

或者我缺少什么?

更新:

之前在此处找到的分步指南已向下迁移到自己的 answer

【问题讨论】:

  • 这太棒了。我处于同样的情况,正在寻找有关此主题的一些信息。这个令牌不违反任何 FB 平台政策是否安全?只是要求确定。
  • @asrijaal Facebook 自己的documentation(看看场景5)说这些页面访问令牌不会过期。我会说可以安全地假设他们遵守 Facebook 的政策。
  • “我认为留下一个清晰的分步过程会很好” - 天堂禁止 :) 谢谢@redhotvengeance
  • 您的页面访问令牌网址有误。应该是一个?不是 & 之后的帐户。花了一段时间试图弄清楚为什么这不起作用。 :P
  • 比你这么多。也 - 到底是什么脸书

标签: facebook facebook-graph-api facebook-access-token


【解决方案1】:

2019 年行之有效的方法

我最近试图实现类似的东西(类似于此线程中描述的用例),但我想确保尊重 Facebook 的当前政策,所以我做了一些研究,在这里我分享我的发现。

我的用例

所以,正如我已经说过的,我的用例与这里描述的非常相似;那就是:

  • 我正在为学区做一些工作。
  • 他们正在使用软件工具来管理与学校交通相关的几乎所有事情。
  • 该工具允许他们在发布公交车延误警报和学校停课警报时向订阅者发送电子邮件通知。
  • 社区中有很多人在他们的 Facebook 页面上关注该组织,这是他们寻找这些警报的唯一地方。
  • 因此,该组织的员工必须在 Facebook 页面上手动发布每个通知(除了在运输软件中创建它)。此外,这些通知最终会过期(或在过期前被删除),因此员工必须稍后再手动删除它们。
  • 时间太长了,所以我们在这里尝试做的是开发一个简单的系统,它会定期轮询软件工具的数据库以获取新的(和过期的)通知,并在 Facebook 页面上更新它们(即添加和删除) .

在我看来,这是一个合法的用例,但我不确定如何以符合 Facebook 政策的方式实施它。

接受的答案

我按照已接受答案的步骤进行操作,但情况似乎发生了变化:现在,即使生成的页面令牌没有过期,access to data 确实会在大约 60 天后过期。如果您按照该过程并检查 FB Token Debugger Tool 中的页面令牌,您也会看到这一点。

此外,生成的页面令牌与用户帐户绑定这一事实也是不幸的,因为如果用户更新他/她的密码,那么页面令牌也会失效。

2019年怎么办

经过几个小时的研究,我偶然发现了以下 Facebook 文档文章:Business Login for Direct Businesses

事实证明,现在可以按照上述文章中描述的步骤,生成与任何特定 Facebook 用户帐户无关且不会过期的页面令牌(除非 FB 应用程序被删除或底层应用程序令牌被删除,你知道...)

以下是步骤和最重要的部分:

  • 您需要一个Business Manager 帐户。
    • 需要验证并且必须签署数字合同。
  • 您需要将目标 Facebook 页面添加到该帐户。
  • 您需要创建一个 Facebook 应用,并将该应用转移到同一个商务管理平台帐户。
  • 该应用必须通过 Facebook 的审核流程,因为需要以下权限:manage_pagespublish_pages
    • 重要提示要使使用生成页面令牌发布的帖子对应用管理员以外的用户可见,该应用需要已发布并获得批准。
    • 您仍然可以在不提交审核的情况下尝试该概念,但这些帖子不会公开显示。
  • 在 Business Manager 帐户中(仅在将您的应用和页面添加到帐户后),您需要创建所谓的系统用户,并赋予该用户管理员角色(或权限)到目标 Facebook 页面。
    • 系统用户归 Business Manager 帐户所有,不与特定用户绑定。我目前的理解是,系统用户的一个主要用例是以编程方式访问 Facebook 的 Graph API(正是我们所需要的)。
  • 然后,对于该系统用户,您需要生成一个访问令牌(该令牌永不过期)。系统将提示您选择哪个应用程序。然后,您将选择您的目标应用程序。
  • 然后您需要使用生成的应用令牌来生成页面令牌,该令牌也将永不过期。该过程在in this article 中描述为:
GET /<PAGE_ID>?fields=access_token&access_token=<SYSTEM_USER_ACCESS_TOKEN>
  • 就是这样。

该令牌永远不会过期,也不会绑定到特定的 Facebook 用户,所以这正是我们所需要的!

最后一部分是确保您的 Facebook 应用程序获得 Facebook 的批准。这实际上是最重要的部分,因为如果人们看不到我们的帖子,整个过程就毫无价值。

我想确定我可以依靠上述程序为我的客户构建一些东西,而 Facebook 最终不会拒绝它,所以,事先(即在开始处理我客户的项目之前),我经历了创建页面、应用程序、业务管理器帐户等的整个过程。我验证了我的业务。我提交了我的应用程序以供审核。在我的请求中,我对我的用例非常具体,并强调该应用程序是“自用”的(即该组织正在为自己开发应用程序,而不是为其他 Facebook 用户)。我在不到 24 小时内就获得了批准。

关于应用审核流程的其他几点说明:

  • 我必须为应用选择一个平台,所以我选择了网站
  • 我必须说明应用为什么需要这两个权限以及如何使用它们。
  • 我必须说明为什么审阅者无法登录我的应用并进行尝试(即因为该应用将由工作进程使用)。
  • 对于强制截屏,我只是在终端中使用curl 实用程序进行手动操作(生成页面令牌并发布到 Facebook 页面)。我还展示了我如何使用 Business Manager 将系统用户链接到页面并生成令牌等等。
  • 再说一次,我对我的用例非常具体,我认为这很有帮助。

我希望这些信息对有类似用例的人有用。

【讨论】:

    【解决方案2】:

    您还可以从 facebook 上的应用仪表板复制和粘贴。 步骤:

    1. 转到https://developers.facebook.com

    2. 在页面右上角选择您的应用 (pic of what it looks like)

    3. 点击左侧选项中的Messenger(会自动进入设置)(pic of what it looks like)
    4. 转到页面中的“令牌生成”部分。选择要为其生成令牌的页面。 (pic of what that section looks like)
    5. 在您需要的地方复制并粘贴您的页面令牌。

    请记住,虽然理论上您的令牌不会过期,但它与您登录的任何 Facebook 帐户直接相关。因此,假设您更改了密码或删除了您的帐户和应用程序之间的权限,那么您的令牌将不再有效。

    【讨论】:

      【解决方案3】:

      非常感谢 @redhotvengeance 提供的分步指南。

      一段时间后,现在Facebook文档中有明确的描述:

      https://developers.facebook.com/docs/facebook-login/access-tokens/expiration-and-extension

      扩展页面访问令牌

      应用可以在页面管理员用户获取页面访问令牌时 使用 manage_pages 权限进行身份验证。如果用户访问 用于检索此页面访问令牌的令牌是短暂的,该页面 访问令牌也将是短暂的。

      要获得更长的页面访问令牌,请交换用户访问权限 一个长期存在的令牌,如上所述,然后请求页面访问 令牌。生成的页面访问令牌不会有任何过期时间。

      【讨论】:

        【解决方案4】:

        这些是以前在问题中的步骤 - 它们已迁移到此答案。

        发现可以生成一个不会过期的 Facebook 页面访问令牌(在 @Igy 的帮助下),这里有一个清晰的分步指南,供所有希望相同的人使用:

        1. 确保您是要从中提取信息的 FB 页面的管理员
        2. 创建一个 FB 应用程序(应该使用与页面管理员相同的用户帐户)
        3. 前往Facebook Graph API Explorer
        4. 在右上角,从“应用程序”下拉列表中选择您创建的 FB 应用程序
        5. 点击“获取访问令牌”
        6. 确保添加manage_pages 权限
        7. 通过调用 Graph API 将这个短期访问令牌转换为长期访问令牌: https://graph.facebook.com/oauth/access_token?client_id=&lt;your FB App ID &gt;&amp;client_secret=&lt;your FB App secret&gt;&amp;grant_type=fb_exchange_token&amp;fb_exchange_token=&lt;your short-lived access token&gt;
        8. 获取返回的新的长期访问令牌
        9. 使用新的长期访问令牌进行 Graph API 调用以查看您的帐户:https://graph.facebook.com/me/accounts?access_token=&lt;your long-lived access token&gt;
        10. 获取 access_token 以获取要从中提取信息的页面
        11. Linttoken 可以看到设置为Expires: Never

        应该这样做。您现在应该拥有一个不会过期的 Facebook 页面访问令牌,除非:

        • 您更改了 Facebook 帐户密码
        • 您失去对目标页面的管理员访问权限
        • 您删除或取消授权您的 Facebook 应用程序

        其中任何一项都会导致访问令牌失效。

        如果您得到(#100) Tried accessing nonexisting field (accounts) on node type (Page),请转到Access Token Debugger,复制User ID 的值,并用它来替换步骤9 中URL 的“我”部分。

        【讨论】:

        • 如何以及在哪里执行第 6 步?
        • @StefanMüller 当您在 Graph API Explorer 页面上单击“获取访问令牌”时,会弹出“选择权限”对话框。 manage_pages 选项位于 Extended Permissions 选项卡下。
        • 太棒了!这就像一个魅力,它作为 PAGE 发布,而不是作为用户发布。
        • 我相信这已经过时了。并且您只会获得一个在大约两个月后到期的访问令牌。
        • 我现在已经完成了所有这些,并且它可以工作,只是长期令牌 ID 在 2 个月后过期并且不是无限的。此外,Acces Token Debugger 在表单底部有一个链接,用于将短期访问令牌扩展到长期访问令牌。
        【解决方案5】:

        Offline Access deprecation 文档中对此进行了介绍

        使用页面管理员的 60 天令牌来检索页面访问令牌(通过 /PAGE_ID?fields=access_token/me/accounts) - 页面访问令牌没有到期时间

        【讨论】:

        • 叹息。确实,这似乎是门票。我可以发誓我尝试了这些步骤的所有可能组合 - 显然我错过了真正有效的那个。一组绝对令人费解的必需操作。非常感谢您的帮助!
        • 网上有这么多作品,这件确实有效。
        • 有没有办法通过javascript代码获得这60天page_access_token?喜欢的方式获取user_access_token > FB.getAuthResponse()['accessToken']; 谢谢!
        猜你喜欢
        • 1970-01-01
        • 2016-03-25
        • 2014-10-18
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2018-02-04
        • 1970-01-01
        • 2014-03-11
        相关资源
        最近更新 更多