2

シンプルなバックグラウンド アプリケーションの概念実証として、Graph API Explorer を使用して、自分のアプリが管理しているページの壁に何かを投稿するためのアクセス トークンを作成しました。うまくいきました。ただし、当然、トークンの有効期限は切れます。

そのため、バックグラウンド アプリケーションが実行されるたびに新しいページ アクセス トークンを自動的に要求するようにしています。そして、それを行う方法の具体的な定義を見つけるのに苦労しています。Facebook とアクセス トークンに関する情報は不足していませんが、バックグラウンド アプリケーションをページに投稿する方法を示すものはないようです。(ユーザーのウォールに投稿しない、バックグラウンド アプリケーションであるためユーザーにログイン ダイアログを表示しない、など)

次の URL への 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);

ページ アクセス トークンを取得するには、最初のアクセス トークンを使用して 2 番目の要求を行う必要があることをいくつかの場所で読みました。しかし、それを行う方法の例が見つからないようです。

誰かが私のためにこれに光を当てることができますか?

  • 私はFacebookページを持っています。
  • 私は、ローカル バックグラウンド アプリケーションがそのページにアクセスする手段を提供する以外の目的を持たない Facebook アプリを持っています。
  • そのアプリケーションが認証できるようにして、ページに何かを投稿できるようにするだけです。
  • (そして、アプリケーションにこれを行う許可を永続的に与えるために Facebook UI で実行する必要がある手順がある場合は、その手順を実行したと思いますが、何らかの形で再確認することをお勧めします。)

編集: 長期間有効なユーザー アクセス トークンを取得し、それを使用してページ アクセス トークンを取得する必要があると説明されています。理論的には、ページ アクセス トークンは期限切れにならないということです。しかし、私にははっきりしないのは、これをどのように達成するかです。

の非推奨について説明しているページと、サーバー側アクセスについて説明しているページをoffline_access読みました。しかし、私は明らかに何かを誤解しています。前者では、適切なトークンを取得するために後者を参照します。ただし、後者には、ユーザーにログインを提示し、アクセス許可を受け入れさせ、そのログインからの応答を使用するための手順が含まれます。

無人で実行されるバックグラウンド プロセスであるため、ユーザー (つまり私) に何らかの質問を提示することは、実際には選択肢ではありません。また、アクセス トークンを取得するためにブラウザーから 1 回限りの要求を行うことはできないと言われました。これは、定義上、クライアント側の対話であり、必要なサーバー側フローの一部ではないためです。(RESTful リクエストが Web ブラウザーから送信されたものかアプリケーションから送信されたものかをサービスが気にするのは奇妙に思えますが、実際にその呼び出しを行うには、OAuth や Facebook API に精通していません。)

では、アプリが Facebook ページに投稿するためのパーマネント アクセス トークンを取得するための手動の手順を実行できるとしたら、それらの手順は何ですか? 逆に、アプリケーションが実行されるたびにアクセスを取得するための自動化された手順をアプリケーションで実行できる場合、それらの手順は何ですか?

(アプリケーションからさらにいくつかの API 呼び出しを行うと、通常は 1 日 1 回のプロセスに 1 秒または 2 秒の実行時間が追加されるため、どのアプローチを採用しても、私には違いはありません。)

4

2 に答える 2

10

最初に、Facebook アプリケーションの設定に入り、非推奨の「オフライン アクセス」権限を再度有効にしました。上記のアプリケーション設定は、次のような URL にあります。

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

ただし、すべてがその設定を「非推奨」と呼んでいるため、それを長期的な解決策として使用したくありませんでした。完全に削除される可能性があり、特定の状況では安全でない可能性があります。推奨される機能を使用することをお勧めします。

そこで、スカベンジャー ハントから更新されたドキュメント、古いドキュメント、時代遅れのインターネット ポストの海、すべての場合に当てはまらない機能についてほとんど仮定を行った PHP コードをまとめてまとめることができたものを以下に示します...

Graph API Explorerにアクセスし、ドロップダウン メニューから Facebook アプリケーションを選択します。[アクセス トークンを取得] をクリックし、必要なアクセス許可を選択します。(私の場合は、[拡張アクセス許可] タブに移動し、[管理対象ページ] と [ストリームの公開] を選択しました。) Facebook アプリケーションが要求しているおなじみの画面が表示されます (私のブラウザーでは新しいタブにありました)。ユーザーは、選択したアクセス許可を付与します。(以前に Facebook アプリケーションの使用に同意したことがある場合は、これを見たことがあるでしょう。)

Graph API エクスプローラーで生成される値 (ランダムな文字の長い文字列) は、「有効期間が短いユーザー アクセス トークン」です。

「シナリオ 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値 (別のランダムっぽい文字の長い文字列) は、「Long Lived User Access Token」です。値は秒単位で、expires60 日に換算されます。

次に、ページ API リファレンスに移動して、ページ アクセス トークンに関するセクションを見てみましょう。これは、ここに例示されている Graph API リクエストの基本構造とともに(access_token非公開情報をリクエストしているため、ここで指定する必要がある指定子を含むサンプル リンクの箇条書きリストが表示されている部分までスクロールします)。ブラウザでこれをリクエストするように導きます：

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

これにより、ユーザー アカウントが制御する Facebook ページと Facebook アプリケーションに関する多くの有用な情報を含む JavaScript オブジェクトが返されます。category私の場合、ページとアプリケーションは同じ名前でしたが、値から、または他のすべてが失敗した場合は値から区別するのは簡単idです。マシンで実行されているバックグラウンド アプリケーションがアクセスしてコピーする必要があるページを見つけますaccess_token(ランダムな文字の 3 番目で最後の長い文字列)。ノード全体は次のようになります。

{
  "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"
  ]
}

これが「Long Lived Page Access Token」です。これは、コードで 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);

おそらく、この「Long Lived Page Access Token」は、「Long Lived User Access Token」のように 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

無人で実行されるバックグラウンド プロセスであるため、ユーザー (つまり私) に何らかの質問を提示することは、実際には選択肢ではありません。

何度も言いますが、一回でいいのです。

有効期限のないページ アクセス トークンを取得し、それをコピーしてアプリに貼り付けます。それ以降、アプリはサーバー側でやりたいことをいつでも実行できます。

また、アクセス トークンを取得するためにブラウザーから 1 回限りの要求を行うことはできないと言われました。これは、定義上、クライアント側の対話であり、必要なサーバー側フローの一部ではないためです。

ユーザー アクセス トークンを取得するためのサーバー側の認証フローも、ブラウザーで部分的に関与する必要があります。

クライアント側の認証フローを介して有効期間が短いトークンを取得し、後でそれを拡張するか、サーバー側の認証フローを使用して有効期間が長いトークンを取得するかは問題ではありません。

(RESTful リクエストが Web ブラウザから送信されたものか、アプリケーションから送信されたものかをサービスが気にするのは奇妙に思えます […])

Facebook は、ユーザーが自分のログイン資格情報を第三者に提供することを望んでいません。そのため、ユーザーアクセス トークンを取得するプロセスは、ユーザーが Facebook にログインして、常にブラウザーで行う必要があります。

では、アプリが Facebook ページに投稿するためのパーマネント アクセス トークンを取得するための手動の手順を実行できるとしたら、それらの手順は何ですか?

manage_pages 権限を持つ有効期間の長いユーザー アクセス トークンを取得します。（または、短命のものを取得して拡張します）。次に、その有効期間が長いトークンを使用して、ドキュメントに記載されている方法で、ターゲット ページのページ アクセス トークンを要求します。

于 2012-11-17T01:32:12.090 に答える