1

デスクトップWebサイトとネイティブiOSアプリケーションの両方を備えた製品に取り組んでいます。両方のコンテキストで、ユーザーのログインオプションとしてFacebook接続を提供しています。

私の意図は、両方のコンテキストで使用するために安全なJSON APIを介して同じFacebookトークンを共有することでした。ユーザーがWebにサインインすると、トークンはバックエンドに保存され、モバイルクライアントが次に実行されたときにトークンをダウンロードできるようになります。そしてそれも使用し、その逆も同様です。（*このアプローチの詳細な理由は、質問の最後に説明しますが、質問に不可欠ではありません。）

問題：iOSクライアントがトークンを使用してフィードダイアログを事前設定する場合、そのトークンがサーバー側のフローを使用してWebによって生成されると、ダイアログのWebビューでエラーが発生します。

「{myappname}でエラーが発生しました。しばらくしてからもう一度お試しください。」

これは確実に再現可能です。

  1. サーバー側のフローを使用して、新しいアクセストークンを生成します。フィードダイアログを使用するため、必ずpublish_actions権限をリクエストしてください。
  2. インコグニートブラウザウィンドウを使用して（空のCookie jarを取得するため）、iOSフィードダイアログがWebビューに表示するm.facebook.comページを表示します：https ：//m.facebook.com/dialog/feed？access_token = SERVER_SIDE_FLOW_ACCESS_TOKEN＆app_id = YOUR_APP_ID＆redirect_uri = fbconnect％3A％2F％2Fsuccess＆sdk = 2＆display = touch

＃2の代わりに、Facebook SDKを使用してダミーのiOSアプリを作成し、それを正しくインスタンス化してダイアログを表示するすべての作業（私はすでに行っています）を行うことができます。エラーを再現するために、m.facebook.comフィードのURLに直接アクセスする方が簡単です。

トークンがサーバー側の認証フローではなく、ネイティブのFacebook iOS SDKによって開始された認証フローによって生成された場合、上記のフィードURLは期待どおりに完全に機能します。

さらに、トークン（モバイルまたはサーバーで生成）は、グラフAPIを介してフィードアイテムを直接投稿するために完全に正常に機能します。問題は、実際にはモバイルフィードダイアログだけにあります。

Facebookは、サーバー側で生成されたトークンがモバイルフィードダイアログコンテキストで動作することを意図的に禁止していますか？

これはm.facebook.comのフィードダイアログエンドポイントのバグですか？

または、うまくいけば、私は何か間違ったことをしていますか？

トークンを共有したいのはなぜですか？

  • offline_access権限が削除されているため、各クライアント（Webとモバイル）は、ユーザーがアクティブなときに他のクライアントに同じトークンを更新させることでメリットを得ることができます。これにより、トークンの有効期限が切れるインスタンスが少なくなるため、ユーザーが最初から再認証する必要があるケースが少なくなります。
  • 同様に、各クライアントは他のクライアントの権限拡張の恩恵を受けることができるため、ユーザーは追加の権限を承認するように頻繁に求められることはありません。
4

1 に答える 1

3

サーバー側の認証から取得するトークンは、クライアント側のトークンとは異なります（私はiOS / Androidをクライアントと見なしています）。サーバートークンは長寿命（60日）ですが、クライアントトークンは短命（数時間）です。

サーバー側のフローは、サーバーがFacebookサーバーに対して認証するセキュリティの別のレイヤーを追加します。これが、このフローを使用するときに、長期間有効なトークンを自動的に取得する理由です。

アクセストークンを使用してデバッガーを試すと、トークンの「オリジン」など、トークンに関する情報を受け取ります。たとえば、クライアント側の認証（jsを使用）から生成されたトークンには「Origin：Web」があります。これは、Facebookが実際にトークンを区別していることを意味します。

私はこれについて100％確信していませんが、FacebookがUIをサーバー側のトークンではなく、クライアントトークンの使用に制限しているように聞こえます。おそらく、ダイアログによってユーザーが必要なしに何かを実行できるためです。アプリの権限を取得するため、60日間のトークンがある場合、アプリはユーザーの代わりにそれを使用して、ユーザーの権限がなくてもユーザーに代わって処理を実行できます。ここで推測しています。

サーバー側でのみサーバートークンを使用し、iOSクライアントに独自のトークンを処理させることをお勧めします。無効および期限切れのアクセストークンの処理ガイドによると、次のように記載されています。

iOSネイティブアプリケーション

APIエラーは、FBRequestDelegateインターフェースによって処理されます。アクセストークンが無効であるか期限切れになっていることを検出した場合、アプリケーションはFacebookiOSアプリにマルチタスクする必要があります。ユーザーがアプリの認証を解除していないと仮定すると、ユーザーは、新しい有効なアクセストークンを使用して、iOSアプリケーションにすぐにマルチタスクで戻ります。

つまり、クライアント側でトークンが期限切れになることを心配する必要はありません。

于 2012-05-10T08:30:03.000 に答える