1

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

为此，我们让用户在设置指向其 Facebook 帐户的链接时授权我们的应用程序。我们获得了publish_stream、offline_access和manage_pages权限（稍后会详细介绍）。

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

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

现在问题来了：

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

从该调用返回的 JSON 据说包含页面 ID 和这些页面的页面访问令牌。然后，您使用页面访问令牌发布到页面的时间线。

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

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

所以我们的访问令牌是有效的，但对这个特定的 url 无效。因此，对于这个特定的提要，我们似乎需要一个用户访问令牌而不是应用程序访问令牌（我早就不在乎为什么会这样，它似乎就是这样）。

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

我不明白。为什么我们可以使用应用程序访问令牌从用户那里获取我们想要的几乎任何数据（好吧，无论他们授予我们获取什么权限），但是/accounts数据我们需要不同的（用户）访问令牌？

任何人都可以阐明我们如何获得用户访问令牌，这将允许我们在不与用户进行任何进一步交互的情况下为我们的用户获取 /accounts 数据？

4

1 回答 1

2

So our access token is valid, but just not valid for this particular url. It seems therefore that we need a user access token and not an app access token for this particular feed

Due to the permissions per type of access token, you do need a valid user access token in this particular case. Read all about access tokens and types. That's just the way it is.

This page describes how to get the elusive user access token by redirecting the user to the auth dialog and asking for the relevant permissions but we need to achieve this without interaction from the user and the user has already given our app all the permissions we need.

If your user already has given his/her permissions, why are you struggling then? I suggest you persist the user access token. From this endpoint:

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

you retrieve a code, like this:

YOUR_REDIRECT_URI?code=OAUTH_CODE_GENERATED_BY_FACEBOOK&state=YOUR_STATE_VALUE

Use this code to generate your user access token, as explained here:

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

This will result in a response like:

access_token=USER_ACCESS_TOKEN&expires=NUMBER_OF_SECONDS_UNTIL_TOKEN_EXPIRES

There it is, your user access token. Persist it. As you can see it expires after the value indicated in the response. If you are using the new API, it should indicate 60 days (that brings me back to this: offline_access is deprecated and results in short-lived - valid for 2 hours - tokens), link. Whenever your user logs in to your app and uses the Facebook integration, the tokens gets refreshed to again, 60 days. This means, that IF your user should not login to your app and use it for 60 days, it will expire.

You can check whether the user access token is expired with:

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

If that does: renew the user access token by using your app access token, it is well documented right over here. But I'm quoting this part:

Server-side Login To obtain a fresh [user] access token in this case you must pass the user through the full server-side Login flow again. However, assuming the user has not de-authorized your app, when you redirect the user to the OAuth Dialog, they will not be prompted to reauthorize your app, and will be immediately redirected to the redirect_uri. This means that the re-authentication process can appear reasonably transparent to the user.

Bottom-line: there are no user access tokens that are valid for ever, the app access token however is. Persist your user access token and check whether it is still valid before performing API calls with it. A normal user should use your app within 60 days and should not just de-authorize your app for fun. Hence the use case in which the user should re-authorize is fairly rare, however, you need to expect it.

于 2012-10-19T20:19:40.180 回答