Facebook開発者向けドキュメントの日本語訳とTips

https://developers.facebook.com/docs/guides/appcenter/

App Centerは優れたソーシャルアプリを見つけ出す場所で、キャンバスアプリ、モバイルアプリ、Facebook連携しているウェブサイトを成長させる新しいチャンネルです。ですので、App Centerへの登録や検索の対象となるよう、アプリの詳細ページを作ることを全開発者にお勧めします。

このドキュメントではアプリの設定手順について解説します。

1. Creating an App Detail Page
2. Uploading Image Assets
3. Authorization
4. Submitting your app for the App Center

Creating an App Detail Page

まだアプリをFacebook Platform上でアプリを作っていない場合は、Apps on Canvas、Facebook Mobile Apps, Facebook for Websitesを参照してください。このページでは、あなたは既にDeveloper Appの扱いに慣れていて、基本設定ができる前提で解説を進めます。

全開発者はDeveloper Appでアプリの詳細ページを作成すべきです。これらのページは、人々がアプリのスクリーンショットを見、特徴を理解し、ログインしてアプリを使い始めるのを助けます。ユーザがアプリの詳細ページから認証手順を完了すると、Facebook上のアプリ、ウェブサイト、モバイルアプリの違いなくアプリへとリダイレクトされます。

App Centerに登録されるには詳細ページは必須で、また、これはFacebook上でアプリを検索する潜在ユーザのランディングページともなります。

詳細ページは必ず、ガイドラインに準拠していなくてはなりません。使い始めた時のユーザ体験を良くするため、このページはアプリがApp Centerに登録される前にレビューされます。

App Centerの設定をするには、Developer Appにアクセスして左側ナビゲーションのApp Centerタブをクリックしてください。

ここに詳細ページに表示する内容を入力します。Display Name（表示名）, Category（カテゴリ）, Description（説明）の値は基本設定と認証ダイアログ設定の値が補完されています。Detailed Description（詳細な説明）フィールドはApp Centerでのみ使われるもので、より長い文章を入力できます。

Support Info（サポート情報）の項目を入力するのも忘れないでください。Advanced Settingsですでに入力済みであれば、その値がここに補完されています。App Centerに登録されるには、開発者は Privacy Policy URL, Terms of Service URLの二つと、User Support EmailもしくはSupport URLを入力しなくてはなりません。

 

Uploading Image Assets

アイコン、バナー、スクリーンショットのアップロードが必要になりますが、アプリがサポートするプラットフォームによって多少変わってきます。たとえば、IOSアプリであればアップロードが必須です。基本設定でサポートするプラットフォームを適切に選択していれば、必須となる画像タイプはApp Centerタブに自動的に表示されます。

画像を作成するときには、以下の点に注意が必要です。

• アプリの名前をバナーに入れる
• 重要なグラフィックには十分なスペースを置く
• 画像の縁にロゴやテキストを置かない
• 以下の例を参照し、ガイドラインに従う

Image Asset Sizes

Icons:

サイズ (px)	表示個所	例
16 x 16	ニュースフィード, ブックマーク
64 x 64	認証ダイアログ, hovercards（右画像のウィンドウ）
96 x 96	モバイルアプリの詳細ページ
128 x 128	ウェブアプリの詳細ページ

Web Promotional Banners:

Size (px)	表示個所	例
155 x 100	メインページ、カテゴリページ、サブカテゴリページのリスト
394 x 150	メインページのトップにある特集（特集に選ばれた場合にのみ使われるオプションです）
180 x 115	ページの右にある特集（特集に選ばれた場合にのみ使われるオプションです）

Mobile Promotional Banners:

App Centerがサポートするモバイルスクリーンの解像度は以下の通りです。

• MDPI: 240 x 480 phones
• HDPI: 480 x 800
• XHDPI: 640 x 960 and up

Size (px)	表示個所
136 x 188  88	メインページ、カテゴリページ、サブカテゴリページの一覧 (MDPI) 注意：本家ドキュメントでも136x188となっているのですが、88ではないかと指摘をいただきました。たしかに188だと一個だけ比率がおかしいです。
204 x 132	メインページ、カテゴリページ、サブカテゴリページの一覧 (HDPI)
272 x 176	メインページ、カテゴリページ、サブカテゴリページの一覧 (XHDPI)

Cover Images:

カバー画像をデザインするときは、上の画像のように128 x 128pxのアイコンが左下を隠してしまうことを忘れないでください。

Size (px)	Display Location
800 x 150	アプリの詳細ページ

Screenshots:

アップロードできるスクリーンショットはプラットフォーム（ウェブ、キャンバス、モバイルウェブ、iPHone、iPad、Android）毎に５枚までです。サポートするプラットフォーム1個につき最低でも1枚のスクリーンショットが必要で、トータルで最低3枚が必要です。

スクリーンショットでは実際のキャプチャ画像を使うべきで、マーケティング用の素材やバナーを含んではいけません。スクリーンショットのサイズは320 x 320 pxから2048 x 2048 pxまでです。

サイズ (px)	表示個所
(320 - 2048) x (320 - 2048)	アプリの詳細ページ

Authorization

App Centerのアプリ詳細画面には新規ユーザが要求されるパーミッション一覧が表示されます。これはAuth Dialogと同じようなもので、新規ユーザがApp Centerから直接アプリをインストールするのを容易にします。

App Center下にあるPremissionの項目を設定する上で、以下のフィールドを入力できます。

1. User & Friend Permissions: ここにあるパーミッションは必須のものとして詳細ページに表示されます。
2. Extended Permissions: ユーザが詳細ページから遷移する過程で、これらパーミッションはオプションとして認証ダイアログで要求されます。ユーザは「x」をクリックしてオプとアウトすることができます。
   
3. Auth Token Parameter: アプリの詳細ページからユーザがアプリを許可した場合、以下のいずれかの形式でアプリに対してアクセストークンが渡されます。
   
   • URI Fragment: クライアントサイドでの認証を行う場合に指定します
   • Query String: サーバサイドでの認証を行う場合に指定します。キャンバスアプリの場合は代わりにsigned_requestが送られます。

App Centerから詳細ページに遷移するユーザもいますが、フィード、リクエスト、広告から直接遷移するユーザもいることを覚えておいてください。それらの場合、これまで通り認証ダイアログを使う必要があります。

キャンバスアプリ開発者の場合：

多くのキャンバスアプリは、クライアントサイドの実装で新規ユーザを認証ダイアログへとリダイレクトします。アプリのページへ直接行くユーザもいますので、この機能は今後も残さなくてはなりません。また、App Centerの設定画面で指定したパーミッションと同じパーミッションを認証ダイアログのscopeパラメータでも指定するよう気をつけてください。これらが一致しない場合、ユーザには２種類の要求を連続してみせられることになり、ユーザ体験は混乱したものになってしまいます。

ウェブサイト開発者の場合：

App Centerの詳細画面からの遷移の過程で認証が済みますので、ユーザがアプリに遷移した段階で既にパーソナライズされたユーザ体験を提供しなければなりません。ユーザが二度目の「Login to Facebook」をクリックするようなことは避けるべきで、代わりにパーソナライズされた情報を表示してユーザ体験を最適化すべきです。ユーザのログイン状態の取得に関してはJavascript SDKとFB.getLoginStatus、それから開発ブログの記事を参照してください。

iOSとAndroid開発者の場合：

モバイルアプリがApp Centerに登録されるには、シングルサインオン（SSO）を使わなくてはなりません。詳細ページからのシームレスなログインを実装しているアプリのみがApp Centerに登録されます。

ユーザはfacebook.com上とFacebookモバイルアプリ両方でApp Centerを閲覧し得ます。ユーザがネイティブアプリを利用しようとする場合、Apple App StoreもしくはGoogle Playへと誘導されます。App Centerはモバイルアプリのマーケットプライスにリンクしますが、これは、iOS, Android, モバイルウェブの優れたソーシャルアプリの成長を助けるための設計です。

Submitting your App for the App Center

アプリがApp Centerに追加されるには、guidelinesに準拠しなくてはなりません。Facebookは画像、アプリの説明、ユーザ体験などをレビューします。アプリが拒否する場合、Facebookは拒否の理由と改善案を説明します。改善が完了したら再度提出して登録を待ってください。

開発者は「Preview」をクリックすることで詳細ページをプレビューすることができ、以下のようにライブプレビューが表示されます。

App Centerの項目最上部にあるボタンをクリックすることでアプリを提出できき、レビュー中を示す文言が表示されるようになります。App Centerに登録されると、このメッセージは更新されます。

注意：アプリの詳細ページを提出すると、結果が出るまでは編集することができません。App Centerに登録されて以降は、いかなる変更もレビューの対象となります。

このプロセスはApp Centerへの登録時に必須ですが、拒否されたとしてもFacebook APIを使ったりブックマーク,リクエスト,タイムライン,ニュースフィードを使い続けることは可能です。App Centerへの登録は必須ではありませんが、これに登録することで新規ユーザ獲得のチャンスが大きくなりますので、是非登録するようお勧めします。

https://developers.facebook.com/docs/opengraph/actionlinks/

オープングラフアクションは、ユーザがアプリ内で取る高レベルなインタラクションです。これらのアクションが投稿されると、アクティビティはユーザのタイムラインと、友だちのニュースフィードやリアルタイムフィードに表示されます。

アクションリンクはいいね！とコメントの横に表示され、友だちは流れてきた投稿から離れること無く、レスポンスとしてアクションを取ることができます。これにより、より少ないクリックでより多くのディストリビューションを持つことができます。

アクションクリックが設定されているアクション投稿

クリック後

アクションリンクは、ビルトインアクションとカスタムアクションに対して設定できます。ユーザがアクションを取り、そのアクションに対する投稿をすると、アクションリンク付きの投稿がユーザのタイムライン,友だちのニュースフィード,リアルタイムフィードに流れます。

ただし、アクションリンクはモバイル端末には表示されないことに気をつけてください。

このドキュメントでは、以下の内容をカバーします。

• 動作: アクションリンクを表示するためのフロー
• 設定: アクションリンクの設定
• 実装をテストする: アクションリンクの実装をデバッグする最良の方法
• FAQ: よくある質問と、デバッグのコツ
• サンプルコード: アクションリンク投稿のサンプル

---

How It Works

ここでは例を示しつつ、アクションリンクの挙動と実装のポイントを紹介します。

Example Flow

ここで紹介する例は、「ユーザがレシピを料理する」アクションを用いる料理アプリです。これを用いて、アクションリンクの投稿とそのフローを紹介します。

1. ユーザ1がアプリ場でアクションを実行し、「レシピを料理」します。アプリはアクションリンクを通じてユーザがレシピを「保存」できるようにします。これは、ユーザはレシピを料理したり保存できると言う事実に基づいています。
2. ユーザ2はユーザ1が「レシピを料理した」投稿を見ます。その投稿中には、いいね！やコメントと並んで、「レシピを保存する」という文言が表示されています。

3. ユーザ２が「レシピを保存する」をクリックすると、Facebookはユーザ２がアプリをインストール済みかチェックします。

   • インストール済みの場合: FacebookはApp Dashboardのアクションリンク設定で指定したエンドポイントを呼びます。この呼び出しではsigned_requestパラメータが渡され、それには以下のデータが含まれています。

     • ユーザ2のアクセストークン
     • ユーザ2のuser_id.
     • 以下の形式のアクションの型<APP_NAMESPACE>:<ACTION>.
     • アクションID（オプション）
     • オブジェクトのURL

     • 以下は、signed_requestの例です。

         {
            "objects": [
               {
                  "url": "http:\/\/www.sugarmedia.com\/nyccookbook\/pizza.html"
               }
            ],
            "action_link": {
               "type": "nyccookbook:save"
            },
            "actions": [
               {
                  "id": "3936222850404"
               }
            ],
            "algorithm": "HMAC-SHA256",
            "expires": 1335830400,
            "issued_at": 1335823862,
            "oauth_token": "12345678901234567890",
            "user": {
               "country": "us",
               "locale": "en_US"
            },
            "user_id": "621273"
         }
       

   • インストールされていない場合:Authenticated Referralsの設定に基づいてユーザ２はリダイレクトされます。

     • Enableになっている場合、ダイアログが表示されてアプリをインストールするよう促します。インストール完了後、ユーザ2はオブジェクトURLへとリダイレクトされます。.
     • Disableになっている場合、ユーザ２はオブジェクトURLへとリダイレクトされます。
     • オブジェクトURLへ遷移したとき、以下のデータが渡されます。
       
       • fb_action_idsパラメータでアクションIDが渡ります。
         
       • fb_action_link_typeパラメータで、<APP_NAMESPACE>:<ACTION>形式でアクションの型が渡ります。
4. アクションリンクを扱うエンドポイントは、"success=>true"もしくは"redirect=>"のいずれかのメッセージを返すことができます。  
   • "success=>true"の場合
     1. ユーザ１が投稿したのと同じオブジェクト（レシピ）に対して、このエンドポイントはユーザ2の代理としてsaveアクションを投稿します。
     2. その後、JSONエンコードされた"success"メッセージを返します。
     3. ユーザ2には、"レシピを保存する"だったアクションリンクが「保存されました（saveアクションの過去形として定義されたもの）」に変更して表示されます。
     4. 注意：ユーザが投稿をリロードしたり再度閲覧した場合、すでに「保存」アクションが投稿されているため、「レシピを保存する」のアクションリンクは表示されません。
   • "redirect=>http://www.myserver.com/somepage"の場合
     1. エンドポイントは、ユーザ2がアプリをインストールするように、もしくはアクションに関する他の情報を表示するために、ユーザ2をFacebookから他のページに対してリダイレクトすることができます。これを行うには、エンドポイントは、JSONエンコードされたredirectメッセージとrecirect_urlを返します。
     2. ユーザ2にはダイアログが表示され、アプリに遷移してプロセスを続行することができると示されます。ユーザはFacebookに留まることが期待されているため、このフローはエラーとして扱われます。

Suppressing Action Links

App Dashboardでアクションリンクを設定している場合、任意のアクション投稿時にno_action_link=trueパラメータを指定することで、アクションリンクが表示されないように設定することができます。

Integration Points

これらは、アクションリンクを適切に扱う上で必要となるステップです。

• App Dashboardでアクションリンクを設定する
• アクションリンクのクリック時に呼び出されるエンドポイントの実装
• オプションとして、Authenticated Referralsの設定（アプリ未インストール状態でアクションリンクをクリックしたユーザに、まずインストールしてから続行させたい場合）。

アプリ設定のステップとサンプルコードを以下で紹介します。

---

Configuration

App Dashboardを使って、任意のアクションに他のアクションが伴うようにアクションリンクの設定をします。

1. まだアクションが用意されていない場合、アクションリンクに使うアクションを用意します。先ほどの例であれば、save(保存する)アクションです。
2. メインとなるcook（料理する）アクションをsaveと繋がるようにします。Advancedセクションを選択し、Linked Actionフィールドにsaveを入力してください。
   
3. アクションリンクを扱うエンドポイントの情報を入力します。このエンドポイントが、アクションリンクのクリック時に呼ばれることになります。このURLはアプリのドメインと一致し、なおかつhttps://で始まるものでなくてはなりません。cookアクションのAdvancedセクションにあるAction Link URLに、そのURLを入力します。
   

Imperative Tenseの項目を変更したい場合があるかもしれません。デフォルトでは現在形の動詞と同じ設定になっています。先ほどの例であればsaveですので、ここは変更しません。

注意：すでにアクションがサブミットされ、Facebook Platformによって許可されている場合、Imperative Tenseの設定は現在形の動詞と同じものになっていて、変更できません。

---

Testing Your Implementation

1. アクション,imperative tense,エンドポイントが設定されていれば、テストを開始することができます。
2. まず、設定済みのアクションを投稿してください。
3. 投稿したのと同じ開発者アカウントで自分のプロフィールを開き、Activity Logを見ます。
   
4. 投稿した内容が表示されますので、タイムスタンプをクリックし、ニュースフィード上での表示の体裁を確かめます。
5. いいね！,コメント,フォローをやめるの横にアクションリンクが表示されていることを確かめます。
   
6. アクションリンクをクリックし、設定したエンドポイントが呼ばれるのを確かめます。
   1. サーバ側でJSONエンコードされたsuccessメッセージを返します。
   2. 先ほどの投稿を見ると、アクションリンクの文言が過去形に置き換わっています。
   3. 開発者アカウントであれば、エンドポイントか返り値で問題があった場合、エラーメッセージが表示されます。

Re-Testing

• 任意のオブジェクトのアクションリンクをクリックした後は、該当ユーザにはアクションリンクが表示されなくなります。テスト中、アクションリンクを再度使えるようにするには、アクションリンク投稿のaction_idを見つけ出し、https://graph.facebook.com/<action_id>に対してHTTP DELETEリクエストを投げます。それ以降ページをリロードすると、アクションリンクは再度表示されているはずです。
  
• 先ほどのサンプルであれば、"cooked a recipe"に対する"saved a recipe"投稿にDELETEリクエストを投げることになります。

---

Frequently Asked Questions

Q: アクションリンクをクリックしたときにアクション投稿をしなかったらどうなりますか？
A: ユーザがアクション投稿を見るとき、毎回アクションリンクが表示されます。ちゃんとアクション投稿をしてこれを止めない限り、ユーザにとって悪いアプリ体験となってしまいます。

Q: アクションリンクはモバイルのニュースフィードにも表示されますか？
A: まだ実装されていませんが、すぐにできるようになります。

Q: アクションリンクからの投稿で要約表示はできますか？
A: はい、アクションリンクからの投稿も通常のアクション投稿と全く同じものですので、同様のプロパティや要約を用いることができます。

Q: httpsで始まるエンドポイントが必要ですか？
A: sandboxモードではない場合に必要です。まだ開発中でsandboxモードがオンになっている場合なら、http://でも大丈夫です。

---

Sample Code

以下にアクションリンクのエンドポイントに用いるサンプルコードを示します。データを受け取り、recipeオブジェクトを保存するアクションを行います。最後にはsuccess=>trueをJSONエンコードして返しています。

<?php

  $app_id = 'APP_ID'; // Your app Id
  $app_secret = "APP_SECRET"; // Your app secret

  // Function to parse an incoming signed request and get the
  // data
  function parse_signed_request($signed_request, $secret) {
    list($encoded_sig, $payload) = explode('.', $signed_request, 2);

    $sig = base64_url_decode($encoded_sig);
    $data = json_decode(base64_url_decode($payload), true);

    if (strtoupper($data['algorithm']) !== 'HMAC-SHA256') {
      error_log('Unknown algorithm. Expected HMAC-SHA256');
      return null;
    }

    // Check the signature
    $expected_sig = hash_hmac('sha256', $payload, $secret, $raw = true);
    if ($sig !== $expected_sig) {
      error_log('Bad Signed JSON signature!');
      return null;
    }
    return $data;
  }

  // Helper function for parsing signed request
  function base64_url_decode($input) {
    return base64_decode(strtr($input, '-_', '+/'));
  }

  // Variable to hold success result
  $success_result = 'false';

  // Parse the signed request
  $parsed_data = parse_signed_request($_REQUEST['signed_request'],$app_secret);
  if ($parsed_data != null) {
    // Get the access token
    $access_token = $parsed_data['oauth_token'];
    // Get the object URL
    $recipe = $parsed_data['objects'][0]['url'];

    // The Graph API endpoint for publishing a save action
    $graph_url_publish = 
      "https://graph.facebook.com/me/nyccookbook:save?access_token=" . $access_token;
    $postdata = http_build_query(
      array(
        'recipe' => $recipe
      )
    );
    $opts = array('http' =>
      array(
        'method'  => 'POST',
        'header'  => 'Content-type: application/x-www-form-urlencoded',
        'content' => $postdata
      )
    );
    $context  = stream_context_create($opts);
    // Publish the save action
    $result = json_decode(file_get_contents($graph_url_publish, false, $context));
    if (($result != null) && isset($result->id)) {
      // Set the result flag to true
      $success_result = 'true';
    }
  }

  // Print the output
  $success = array(
    'success' => $success_result
  );
  $output = json_encode($success);
  echo $output;
?>

ユーザがFacebook側でアプリを削除してしまった場合、それを知るにはどうするのが良いんだろうという話があったので、その時の対処方法の共有です。

自分のサービス内に退会ページを設置でき、それをユーザが使ってくれれば単純なのですが、Facebookアプリの場合、ユーザはFacebook上の管理画面からアプリを削除してしまうことができます。この場合、アプリ側で削除処理を知ることができず、ユーザのデータが公開されたまま残ってしまったりして厄介な場合があります。

その場合の対応として、ドキュメントのAuthenticationのApp Deauthorizationという項目には以下の方法が紹介されています。

ユーザがApp Dashboardからアプリケーションを取り除いてしまったり、News Feedでアプリケーションをブロックすると、アプリケーション側はDeveloper Appで指定する Deauthorize Callback URLから通知されます。アプリケーションを取り除くとき、HTTP POSTリクエストでsigned_requestというパラメータが送られ、デコードすると削除したユーザのuser_idを含むJSONオブジェクトになります。このリクエストではユーザのaccess tokenは渡されず、また、この時点で該当ユーザのaccess tokenは全て無効になります。

日本語でFacebookを利用している場合、この設定項目は「アプリ設定画面 > 詳細 > 認証拒否時のコールバック先」で設定できます。

このsigned_requestのデコードの方法や、デコードして得られるJSONオブジェクトの各種フィールドについてはSigned Requestの和訳を参照してください。

Facebookアプリを使う上で必要となるのがユーザのアクセストークンですが、これは通常2時間で無効になってしまいます。それを回避する上で便利なのがoffline_accessというパーミッションですが、これは今年5月2日から使えなくなってしまいます。
（*ちょっと前までは5月1日で廃止となっていたのですが、いつの間にか2日にズレていました。けど1日と書かれたままの部分もあります。）

対応をまとめたものが残っていたので、今回はそれを紹介します。
以下、その時の資料です。

access_tokenとpermission

ユーザのデータにアクセスしたり、ユーザの代理としてfacebook投稿などするには、アクセストークンだけでなく、必要に応じた許可（パーミッション）を得る必要がある。ユーザ自身の特定の情報にアクセスするためのもの、ユーザの友達に関する特定の情報にアクセスするものや、イベントの作成と参加／不参加表明などの書き込み系のものなど、権限は色々。
メッセージボックスの中身を見るパーミッションもある。

offline_accessパーミッションで何が出来るか

offline_access

Enables your app to perform authorized requests on behalf of the user at any time. By default, most access tokens expire after a short time period to ensure applications only make requests on behalf of the user when they are actively using the application. This permission makes the access token returned by our OAuth endpoint long-lived.

このパーミッションを得ておくと、通常は短期間（2時間と言われてる）で無効になるaccess_tokenが長期間使えるようになる。ユーザが２時間以上滞在した場合も再ログインさせてtokenを更新する必要がないので、The New York Times, Yahoo!などのニュースサイトでも使われてる。買収されたGowallaも。また、ユーザがオフラインの状態でもユーザの代理としてAPI叩けるので、バッチ処理用に取得してる場合もある。

ロードマップ

http://developers.facebook.com/roadmap/

offline_access Permission Removal
The offline_access permission is deprecated and will be removed May 1, 2012. Until then, you can turn this change on or off using the "Deprecate offline access" migration. Please see the Removal of offline_access Permission doc for more details.

今は移行期間なので、offline_accessパーミッションを有効／無効にするオプションがアプリ設定にある。この設定変更が有効なのは2012/05/01まで。それ以降はoffline_accessは使えなくなる。

アプリの設定

https://developers.facebook.com/docs/offline-access-deprecation/
上記ページのGetting started with the new migration settingに従ってアプリのセッティングをする。
これによりoffline_accessは使えなくなり、access_tokenの新しいルールが適用されるようになる。
以降は60日有効なaccess_tokenが与えられる。

以後のアクセストークンの更新

クライアントサイド更新

ttps://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

EXISTING_ACCESS_TOKEN(既存のアクセストークン)も期限が来るまでは使い続けられるけど、更新したなら新しい方を使うのが良い。

サーバサイドでの更新

ドキュメント内のサーバーサイド手順解説へのリンク（https://developers.facebook.com/docs /authentication/server-side/）が死んでる。多分正しいのは Authentication のServer-side Flowの項目

Note: The user must access your application before you're able to get a valid "authorization code" to be able to make the server-side oAuth call again. Apps will not be able to setup a background/cron job that tries to automatically extend the expiration time, because the "authorization code" is short-lived and will have expired.

access_tokenの再取得には、これまでの手順通り、ユーザのauthorization codeが必要。authorization codeは短期間で無効になるので、再取得するにはユーザのログイン手順を踏む必要がある => 毎時のバッチ処理などでユーザの関与無しに再取得するのはダメ。

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

注意

今まで通り、ユーザがパスワードを変えたりアプリを削除したタイミングでaccess_tokenは無効になる。

対応

必要だった箇所を洗い出す。（ウォールへの投稿のみであれば、publish_streamsパーミッションとアプリ自身のアクセストークンで足りるので何もしないで大丈夫）
2時間毎にトークン無効 => 再度ログイン手順を踏ませる、というのを避けるためだったのならば、今後は最大60日有効になるから大丈夫。