1

ユーザーが新しいブログエントリを作成するたびに、ユーザーのFacebookタイムラインへのリンクを公開するように構成できるオーディオブログWebサイトがあります。

これを行うために、ユーザーがFacebookアカウントへのリンクを設定するときに、ユーザーにアプリを承認してもらいます。publish_stream、offline_access、manage_pagesの権限を取得します（これについては後で詳しく説明します）。

すべてのコードはC＃ですが、関係するFacebook APIの動作であるため、原則はすべての言語に適用されます。これらすべてを実現するために、 OAuth2とGraphAPIを使用しています。

そのため、アプリIDとシークレットを使用してアプリアクセストークンを取得し、そのトークンを使用してユーザーのタイムラインに公開します。これは正常に機能します（ユーザーがアプリにこれを行うことを既に許可しているため）。また、Graph APIにクエリを実行して、彼らのいいね、友達、その他のさまざまなデータを取得することもできます。

ここに問題があります：

一部のユーザーは、自分のタイムライムと、管理しているページのタイムラインの更新を公開したいと考えています。理論的には、これは単純です。次のURLを使用して、ユーザーが管理するページのAPIをクエリします。https：//graph.facebook.com/ {userid} / accounts？access_token = {token}

この呼び出しから返されるJSONには、それらのページのページIDとページアクセストークンが含まれていると言われます。次に、ページアクセストークンを使用して、ページのタイムラインに公開します。

ただし、アプリアクセストークンを使用してこのURLを呼び出そうとすると、 「このリソースを要求するにはユーザーアクセストークンが必要です」というOAuthException102が発生します。

これは、OAuthException 104「このリソースを要求するにはアクセストークンが必要です」（アクセストークンの受け渡しを怠った場合に取得されるもの）、およびOAuthException 190「無効なOAuthアクセストークン署名」（アクセストークンが有効なものでない場合に取得されます）。

したがって、アクセストークンは有効ですが、この特定のURLには無効です。したがって、この特定のフィードにはアプリアクセストークンではなく、ユーザーアクセストークンが必要なようです（私はこれが事実である理由をずっと気にかけていませんが、それはまさにその通りのようです）。

このテーマに関するすべてのFacebookドキュメント（そして私は今までにすべてを読んだはずです）は1つの場所につながります：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 に答える