2

作为一个简单后台应用程序的概念证明，我使用 Graph API Explorer 为我的应用程序创建了一个访问令牌，以将某些内容发布到我维护的页面的墙上。它工作得很好。但是，令牌自然会过期。

所以现在我试图让后台应用程序在每次运行时自动请求一个新的页面访问令牌。而且我很难找到如何做到这一点的具体定义。关于 Facebook 和 Access Tokens 的信息并不缺乏，但似乎没有什么可以说明如何将后台应用程序发布到页面。（不张贴到用户的墙上，不向用户显示登录对话框，因为它是后台应用程序等）

通过读取来自 Web 请求的响应，我可以很容易地在代码中获取访问令牌：

https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id={MY_APP_ID}&client_secret={MY_APP_SECRET}

当然，当试图发布到页面的墙上时，那个“访问令牌”不起作用。它表示用户尚未授权应用程序执行此操作。我正在执行的操作非常简单：

var client = new FacebookClient(GetFacebookAccessToken());
dynamic parameters = new ExpandoObject();
parameters.message = "this is a test";
dynamic result = client.Post("{MY_PAGE_ID}/feed", parameters);

我在某些地方读到，我需要使用第一个访问令牌发出第二个请求，以获取页面访问令牌。但我似乎找不到如何做到这一点的例子。

有人可以为我解释一下吗？

  • 我有一个 Facebook 页面。
  • 我有一个 Facebook 应用程序，除了为本地后台应用程序提供访问所述页面的方法外，没有其他目的。
  • 我只需要该应用程序能够进行身份验证，以便它可以将某些内容发布到页面。
  • （如果我需要在 Facebook UI 中执行某个步骤以永久授予应用程序执行此操作的权限，我想我已经执行了该步骤，但最好以某种方式仔细检查。）

编辑： 有人向我描述，我需要获得一个长期存在的用户访问令牌，并使用它来获得一个页面访问令牌。理论上，所述页面访问令牌不会过期。但是，我不清楚的是如何做到这一点。

我已经阅读了描述弃​​用的页面offline_access，以及描述服务器端访问的页面。但是，我显然误解了一些东西。在前者中，它引用后者来获取正确的令牌。然而，后者包括向用户显示登录、让他们接受权限以及使用来自该登录的响应的步骤。

作为一个无人值守的后台进程，向用户（可能是我）提出任何类型的问题并不是一个真正的选择。我还被告知，我不能从浏览器发出一次性请求来获取访问令牌，因为根据定义，这是客户端交互，而不是必要的服务器端流程的一部分。（我觉得奇怪的是，服务会关心 RESTful 请求是来自 Web 浏览器还是来自应用程序，但我对 OAuth 或 Facebook API 还不够熟悉，无法真正进行调用。）

那么，如果我可以执行一些手动步骤来获取应用程序的永久访问令牌以发布到 Facebook 页面，那么这些步骤是什么？相反，如果我可以在应用程序中执行一些自动化步骤以在每次运行时获取访问权限，那么这些步骤是什么？

（从应用程序进行更多的 API 调用会为原本一天一次的流程增加一到两秒的运行时间，因此对我来说采用哪种方法没有区别。）

4

2 回答 2

10

起初我只是进入 Facebook 应用程序设置并重新启用已弃用的“离线访问”权限。可以在这样的 URL 中找到所述应用程序设置：

https://developers.facebook.com/apps/{APPLICATION_ID}/advanced

但是，由于所有内容都将该设置称为“已弃用”，因此我不想将其用作长期解决方案。它可能会被完全删除，在某些情况下可能不安全，等等。最好使用推荐的功能。

所以这就是我通过更新的文档、过时的文档、大量过时的互联网帖子和 PHP 代码从寻宝中拼凑起来的东西，这些代码大多对并非在所有情况下都正确的功能做出假设......

访问Graph API Explorer并从下拉菜单中选择您的 Facebook 应用程序。单击“获取访问令牌”并选择所需的权限。（对于我来说，我转到“扩展权限”选项卡并选择“托管页面”和“发布流”。）您将被提示（在我的浏览器中，它位于一个新选项卡中）与 Facebook 应用程序询问的熟悉屏幕您，用户，授予它您刚刚选择的权限。（如果您以前曾同意使用 Facebook 应用程序，那么您之前已经看到过。）

它在 Graph API Explorer 中产生的值（一长串随机字符）是您的“短期用户访问令牌”。

如“场景 4：客户端 OAuth 和通过新端点延长 Access_Token 过期时间”中所述，在您的 Web 浏览器中访问此 URL ：

https://graph.facebook.com/oauth/access_token?
  client_id={APPLICATION_ID}
  &client_secret={APPLICATION_SECRET}
  &grant_type=fb_exchange_token
  &fb_exchange_token={SHORT_LIVED_USER_ACCESS_TOKEN}

（您可以{APPLICATION_SECRET}在您的 Facebook 应用程序的基本设置页面上获取该值https://developers.facebook.com/apps/{APPLICATION_ID}/summary：）

这将返回另一个访问令牌，如下所示：

access_token={LONG_LIVED_USER_ACCESS_TOKEN}&expires=5184000

这个access_token值（另一个长串随机字符）是您的“长期用户访问令牌”。该expires值以秒为单位，转换为 60 天。

现在我们跳到Page API 参考并看一下Page Access Tokens部分。这一点，连同此处举例说明的 Graph API 请求的基本结构（向下滚动到它显示包含说明符的示例链接的项目符号列表的部分access_token，您需要在此处指定这些说明符，因为您正在请求非公开信息）引导您在浏览器中请求：

https://graph.facebook.com/{FACEBOOK_USER_ID}/accounts?
  access_token={LONG_LIVED_USER_ACCESS_TOKEN}

这将返回一个 JavaScript 对象，其中包含有关您的用户帐户控制的 Facebook 页面和 Facebook 应用程序的大量有用信息。在我的情况下，页面和应用程序具有相同的名称，但是很容易将它们与值区分开来，category或者，如果所有其他方法都失败，则可以将它们区分开来id。找到您机器上运行的后台应用程序需要访问的页面并复制它access_token（第三个也是最后一个随机字符长字符串）。整个节点看起来像这样：

{
  "name": "Some Facebook Application Name",
  "access_token": "{LONG_LIVED_PAGE_ACCESS_TOKEN}",
  "category": "Musician/band",
  "id": "{APPLICATION_ID}",
  "perms": [
    "ADMINISTER",
    "EDIT_PROFILE",
    "CREATE_CONTENT",
    "MODERATE_CONTENT",
    "CREATE_ADS",
    "BASIC_ADMIN"
  ]
}

这是您的“长寿命页面访问令牌”。这是您在代码中用于初始化 FacebookClient 对象的值。然后，发布一个简单的状态更新就像这样简单：

var client = new FacebookClient("{LONG_LIVED_PAGE_ACCESS_TOKEN}");
dynamic parameters = new ExpandoObject();
parameters.message = "This is a my status update.";
dynamic result = client.Post("{FACEBOOK_PAGE_ID}/feed", parameters);

假设这个“长寿命页面访问令牌”不会像“长寿命用户访问令牌”那样在 60 天后过期。我想我会在 59 天内找到答案。

注意：我的示例中的花括号是实际值占位符的一部分。不要在实际请求中使用花括号。所以是这样的：

https://developers.facebook.com/apps/{APPLICATION_ID}/advanced

变成这样，例如：

https://developers.facebook.com/apps/123456/advanced

123456实际的 Facebook 应用程序 ID在哪里。

于 2012-11-17T21:45:07.127 回答
-1

作为一个无人值守的后台进程，向用户（可能是我）提出任何类型的问题并不是一个真正的选择。

正如我已经说过的，您只需执行一次。

您获得了不会过期的页面访问令牌，将其复制并粘贴到您的应用程序中——从那时起，您的应用程序就可以在服务器端做任何它想做的事。

我还被告知，我不能从浏览器发出一次性请求来获取访问令牌，因为根据定义，这是客户端交互，而不是必要的服务器端流程的一部分。

用于获取用户访问令牌的服务器端身份验证流程也需要部分参与浏览器。

没关系，您是通过客户端身份验证流程获得短期令牌并在之后扩展它，还是使用服务器端身份验证流程获得长期令牌。

（我觉得奇怪的是，服务会关心 RESTful 请求是来自 Web 浏览器还是来自应用程序 [...]）

Facebook 不希望用户将其登录凭据提供给任何第三方。因此，获取用户访问令牌的过程总是必须参与浏览器，用户登录到 Facebook。

那么，如果我可以执行一些手动步骤来获取应用程序的永久访问令牌以发布到 Facebook 页面，那么这些步骤是什么？

获取具有 manage_pages 权限的长期用户访问令牌。（或者得到一个短暂的，并延长它）。然后，按照文档中描述的方式，使用该长期令牌请求目标页面的页面访问令牌。

于 2012-11-17T01:32:12.090 回答