Facebook的图形API：让应用访问令牌，需要用户访问令牌不互动 [英] Facebook Graph API: Have app access token, need user access token without interaction

问题描述

我们有一个音频博客网站，可以配置为发布链接到用户的Facebook时间轴时，他们做出一个新的博客条目。

要做到这一点，我们有用户授权我们的应用程序时，他们建立了链接到他们的Facebook账户。我们获得的 publish_stream offline_access 和 manage_pages 权限（稍后更多）。

所有的代码是在C＃中，但原则适用于任何语言，因为它是在 Facebook的API的运作：我们所关心的。我们使用的的OAuth 2 和图形API ，以实现这一切。

所以，我们得到应用访问令牌用我们的应用ID 和秘密并使用该令牌发布到用户的时间线，这工作正常（因为他们已经授权我们的应用程序做到这一点）。我们也可以查询图形API，并得到他们的喜欢 朋友和其他各种数据。

现在，这里的问题是：

我们的一些用户希望发布的更新自己的timelime，也给网页它们管理的时间表。从理论上讲，这是简单的：您查询API为用户管理使用此URL的网页：的 {https://graph.facebook.com/用户ID} /帐户？=的access_token {}令牌

的

从JSON返回此呼叫被认为包含用于那些页面的页面ID和页面访问令牌。然后，使用页面访问令牌发布到网页的时间表。

然而，当我们试图把这个网址与应用访问令牌我们得到一个OAuthException的 102 用户访问令牌需要请求此资源。

请注意这是OAuthException不同的 104 访问令牌需要请求此资源（这是，如果你忽略了传递一个访问令牌，你会得到什么），也OAuthException的 190 无效OAuth访问令牌签名（你会得到，如果访问令牌不是有效的）。

所以我们的访问令牌是有效的，但只是不适用此特定的URL。因此看来，我们需要一个用户访问令牌而不是应用访问令牌作为这个特殊的饲料（我早已过去照顾，为什么是这样的话，它只是似乎，是事情是这样的）

所有关于这一问题的Facebook的文件（我现在一定读这一切）导致一个地方：的 http://developers.facebook.com/docs/authentication/server-side/ ，又名服务器端身份验证流程页面。本页面描述了如何通过将用户重定向到身份验证对话框，要求输入相关权限以获得难以捉摸的用户访问令牌，但我们需要做到这一点无需用户和用户交互已经给我们的应用程序的所有权限我们需要。所有这一切都自动发布的发生服务器端在音频的后期处理，所以我们不能在现阶段反正用户交互。

我不明白这一点。为什么我们可以使用该应用程序访问令牌来获得我们从用户想要的（好吧，不管他们给我们的许可来获得），但在 /帐户数据，我们需要一个不同的（用户几乎所有的数据）访问令牌？

任何人都可以摆脱对我们如何才能获得令牌的用户访问，这将使我们能为我们的用户/账户数据没有任何进一步的光从用户的交互？

解决方案

所以我们的访问令牌是有效的，只是不适用于此特定的URL。因此看来，我们需要一个用户访问令牌而不是应用访问令牌作为这个特殊的饲料。

由于每种类型的访问令牌的权限，你就需要在这种特殊情况下的有效用户的访问令牌。 阅读所有有关访问令牌和类型。这只是事情是这样的。

本页面介绍了如何通过将用户重定向到身份验证对话框，并要求获得难以捉摸的用户访问令牌对于相关权限的但我们需要做到这一点无需用户和用户交互已经给我们的应用程序，我们需要的所有权限。

如果您的用户已经给他/她的权限，你为什么挣扎呢？我建议你​​坚持用户访问令牌。从这个端点：

  https://www.facebook.com/dia​​log/oauth?client_id=..&redirect_uri=..&state=..&scope=..& RESPONSE_TYPE = ..&安培;显示器= ..
  

您检索代码，如：

  YO​​UR_REDIRECT_URI码= OAUTH_CODE_GENERATED_BY_FACEBOOK&放大器;状态= YOUR_STATE_VALUE 
  

使用此代码来生成你的用户访问令牌，如解释的这里：

  https://graph.facebook.com/oauth/access_token？ CLIENT_ID = ..&安培; REDIRECT_URI = ..&安培; client_secret = ..&放大器;代码= .. 
  

这将导致一个响应，如：

 的access_token = USER_ACCESS_TOKEN&安培;到期= NUM​​BER_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 
  

如果这并：使用你的应用程序访问令牌，这是有据可查的 -tokens /」相对=」nofollow的>右键超过在这里，但我引用这个部分：

服务器端登录
，获取新的[用户]访问令牌在这种情况下，你必须再次通过全服务器端登录流程的用户。然而，假设用户没有取消授权您的应用程序，当你将用户重定向到OAuth的对话，他们将不会被提示重新授权您的应用程序，并且将立即重定向到REDIRECT_URI。这意味着重认证过程可以出现合理对用户透明的

底线：有没有用户访问令牌该是有效的，直到永远，应用程序访问令牌不过是。坚持你的用户访问令牌和检查它是否仍然是它在执行API调用之前有效。普通用户应在60天内使用你的应用程序，不应该只是去检查你的有趣的应用程序。因此，使用情况，用户应重新授权是相当罕见的，但是，你需要指望了。

We have an audio blogging website which can be configured to publish links to the user's Facebook timeline whenever they make a new blog entry.

To do this, we have the user authorise our app when they set up the link to their Facebook account. We obtain the publish_stream, offline_access and manage_pages permissions (more on that later).

All the code is in C# but the principles apply to any language as it's the workings of the Facebook API we are concerned with. We're using OAuth 2 and the Graph API to achieve all of this.

So, we obtain an app access token using our app ID and secret and use that token to publish to the user's timeline, this works fine (because they have already authorised our app to do this). We can also query the Graph API and get their likes, friends and various other data.

NOW HERE IS THE PROBLEM:

Some of our users want to publish updates to their own timelime and also to the timelines of pages that they manage. In theory this is simple: you query the API for the pages that the user manages using this url: https://graph.facebook.com/{userid}/accounts?access_token={token}

The JSON returned from this call is said to contain the page IDs and the page access tokens for those pages. You then use the page access token to publish to the pages' timelines.

However, when we try to call this URL with the app access token we are getting an OAuthException 102 "A user access token is required to request this resource".

Note this is different to OAuthException 104 "An access token is required to request this resource" (which is what you'd get if you neglected to pass an access token), and also OAuthException 190 "Invalid OAuth access token signature" (which you would get if the access token was not a valid one).

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 (I am long past caring why this is the case, it just seems to be the way it is).

All the Facebook documentation on this subject (and I must have read all of it by now) leads to one place: http://developers.facebook.com/docs/authentication/server-side/, aka the "Server-Side Authentication Flow" page. 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. All of this automated publishing happens server side in the post-processing of the audio so we cannot interact with the user at this stage anyway.

I don't get it. Why is it we can use the app access token to get almost any data we want from the user (well, whatever they have given us permission to get) but the /accounts data we need a different (user) access token for?

Can anyone shed any light on how we can get a user access token which will allow us to get the /accounts data for our users without any further interaction from the user?

解决方案

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.

这篇关于Facebook的图形API：让应用访问令牌，需要用户访问令牌不互动的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！