あなたが私に怒鳴り始める前に、私は多くのユーザーがすでにこのようなことを求めていることを知っていますが、私はそれらすべてを読み、私の特定のケースに関連する返信を見つけることができませんでした.私 (および他の開発者) は探しています。これについての私の経験を皆さんと共有したいので、私のシナリオと、これを処理する方法を調べるために従った手順を説明しようと思います。私と同じ状況にある一部の開発者の心をクリアにするのにも役立ちます.
Facebook API を利用するネイティブ Android アプリケーションを作成しました。デバイスにインストールされている公式アプリに依存したくないので、私は Facebook SDK を使用しません (実際のところ、私のアプリはそのアプリの一部に代わるものであるため、とにかく最初にインストールする必要があります)、私は HTTP を介して直接 Graph API 呼び出しを発行し、応答を自分で処理します。それがあなたが私に与えることを考えている答えであるなら、私はその道をたどらないので、しないでください.
そのため、クライアント側の認証を利用してアプリを承認し、URL を WebView に表示して、最後に access_token を取得しました。他のアクセス許可の中でも特に offline_access を要求しました。
offline_access は 5 月に非推奨になる予定なので、とにかく長寿命のトークンを取得する方法を調査し始めたので、もちろん公式のガイドラインを含め、それに関連するほとんどすべてを読みました。簡単に言えば、私にとっては何もうまくいきませんでした.
これは私が始めたものです：
- 設定で私のアプリのoffline_accessを廃止しました（現在多くのユーザーが使用しているためアプリではありませんが、基本的に同じであり、テスト目的でのみ使用する別のアプリなので、同じことです）。
- クライアント側認証を使用してユーザーを承認しました: https://www.facebook.com/dialog/oauth?client_id=MY_APP_ID&redirect_uri=http://my.domain.com/yeah.htmlscope=publish_stream,read_stream,user_photos,friends_photos,offline_access&response_type =トークン&ディスプレイ=ワップ
私は access_token を取得しましたが、それがまったく長続きしないことにすぐに気付きました。まったく逆で、expires_in は 6800 秒 (2 時間未満) のように設定されていました。したがって、私が立てた最初の仮定 (access_tokens はデフォルトでより長く存続する) はすでに間違っていました。
次に、この access_token の有効期間を延長する方法を調べ、ほとんどすべての代替手段を試しました。言うまでもなく、すべての試みが失敗しました。正確には、それが私が試したことです：
- まず第一に、もちろん、新しいエンドポイントを介してトークンを拡張する「公式」アプローチを試しました。そのような操作のためにクライアント シークレットを要求することがいかに愚かであるかについての暴言はここではスキップします (多くの人がすでに指摘しているように、そのようなシークレットは Android アプリに埋め込む必要があります。これは、開発者にとってセキュリティ上の悪夢です。ユーザーに代わってトークンの寿命を延ばすためにこのビットをサーバー側に移動することは、代わりに彼らにとって悪夢です。正しいパラメーターを使用したそのアドレス: https://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN...リクエストは成功したようですが、何の寿命も延長しませんでした。リクエストは、以前と同じ access_token を返しましたが、expires_in パラメーターには、流れ去る時間の砂が反映されています (以前と同じ値から、承認してから経過した秒数を差し引いたものです)。基本的に、そのメソッドは、何も更新したり変更したりせずに、すでに利用可能な access_token がどれだけ存続するかを教えてくれるだけなので、明らかにセキュリティ上の懸念が生じるにもかかわらず、それもかなり役に立ちません。
- 次に、他の誰かが提案したことを試しました。つまり、古いREST APIを使用してジョブを実行し、GETリクエストを次のアドレスに発行します: https://api.facebook.com/method/auth.extendSSOAccessToken?access_token=EXISTING_ACCESS_TOKENこれは明らかに悪名高い「シングルサインオンを使用してアクセストークンを取得できませんでした」というエラーで失敗しました。
それらの試みが失敗した後、私はそれらすべてが失敗した原因は何かを考え始めました. 予想どおり、私のアプリは Android デバイスで実行されますが、API への HTTP リクエストを直接トリガーします。これが問題の原因である可能性があります。
- 開発者アプリ ページの高度なセクションで、アプリが「ネイティブ/デスクトップ」ではなく「ウェブ」として構成されていました。とは言っても、「ネイティブ/デスクトップ」に変更しても、最初のログアウト時に有効期間の長い access_token が得られるだけでした (1 ～ 2 時間ではなく約 24 時間)。
- 公式のガイドラインには、興味深い、非常に気味の悪い段落があります。これは多くの人に見落とされているようですが、これが問題の原因である可能性があると考え始めたので、別のアプローチを試しました。つまり、クライアント側ではなくサーバー側の認証を試しました。 client_secret が必要なため、Android アプリのばかげたソリューションになりますが、とにかく試してみたかったのです。そのため、最初にコードを取得し、次に access_token を取得しました ( http://developers.facebook.com/docs/authentication/server-side/で説明されているように)）。これにより、access_token の有効期間が大幅に長くなりました (5183882 秒、つまり約 59 日) が、それを拡張するための既知の手段 (この場合は実際には必要ではなかったとしても) は両方とも同じ結果になりました: 前者は更新されません。後者は、SSO 経由で取得されなかったという事実について不平を言っています。
つまり、非常に長い話になりますが (遅すぎることは承知しています)、offline_access の廃止期限が近すぎて首に息を吹きかけているように感じますが、何も機能していないようです。このすべてについてあなたはどのような経験をしていますか? もしあなたが私と同じ船に乗っていて、なんとかそれを機能させることができたなら、どのようにしましたか?
お待ち頂きまして、ありがとうございます。