8

Facebookのキャンバスアプリを持っています。JS SDKを使用して、ブラウザー側でユーザーを認証し、FB.apiを介してさまざまな情報（名前、友達など）を要求しています。

また、ajax呼び出しを行うことにより、サーバー上のデータベースにいくつかの追加のユーザー情報（Facebookには保持されていません）を保持したいと思います。

{ userFavouriteColour: "Red" }

これをサーバーに保存して正しいユーザーに関連付けるには、Facebook uidを知る必要があり、これには問題があります。クライアントからサーバーにuidを渡すにはどうすればよいですか。

オプション1：uidをajaxリクエストに追加します：

{ uid: "1234567890",
  userFavouriteColour: "Red" }

これは明らかに良くありません。他の人のFacebookIDを使用して私のWebサービスにajaxリクエストを送信し、お気に入りの色を変更するのは簡単です。

オプション2：サーバーで、Cookieからuidを抽出します：これも可能ですか？Facebookがuidとアクセストークンを含むCookieを設定することを読みましたが、ドメインでこのCookieにアクセスできますか？さらに重要なことに、Cookieからuidを安全に抽出できますか、それともオプション1と同じようになりすましが可能ですか。

オプション3：サーバーでのユーザーサーバー側認証：サーバー側認証を使用して、サーバーでユーザーIDを検証できます。しかし、ブラウザですでにクライアント側の認証を使用している場合、これは機能しますか？最終的に2つの異なるアクセストークンになりますか？ブラウザからFB.apiリクエストを作成したいので、（サーバーだけでなく）クライアントにアクセストークンが必要です。

これは非常に一般的なシナリオであるに違いないので、基本的な何かが欠けていると思います。Facebookのドキュメント（さまざまな認証フロー、アクセストークン、signed_requestなど）とSOに関する多くの投稿を読みましたが、クライアント側の認証とサーバー側の認証がどのようにうまく連携するかはまだわかりません。

つまり、サーバー上のユーザーのIDを知りたいのですが、それでもクライアントブラウザーからFacebook APIにリクエストを送信しますか？

（サーバーでASP.NETとFacebook C＃SDKを使用しています）

編集：報奨金を追加しました。私は、この状況に対処する方法について、より明確で公式な推奨事項、または例さえも入手したいと思っていました。すでに述べたように、認証フローに関する公式のFBドキュメントをすでにたくさん読んでいますが、クライアント側とサーバー側の認証がどのように連携するかについて明確なものはまだ見つかりません。

4

4 に答える 4

3

オプション1： 私が考えることができる最も簡単な方法は、accessTokenをJSに含め、それをajax呼び出しで渡すことです。

オプション2： オプション1と同じ方法を使用しますが、accessTokenだけを送信する代わりに、signedRequestを送信します。

サーバー側では、（TryParseSignedRequestメソッド）を使用してデコードできます。これによりUserID:-)が得られます。

注：signedRequestアプリケーションシークレットで暗号化されます。あなたはそれを知っているべき唯一の人なので、あなたはその目的で安全です。

免責事項：

私はC＃でのコーディング経験がありませんが、グーグルで少し検索すると次のようになります。

Facebook C＃SDK for ASP.NET

Facebook C＃SDKを使用してAJAXリクエストを作成する

于 2012-05-29T15:48:14.327 に答える
1

実はとても簡単です。

ユーザーがアプリを読み込むときは、サーバー側の認証を使用し、アクセストークンを取得し、サーバーからapiリクエストを発行してユーザーデータを読み込みます。
サーバー側では、必要なものがすべて揃っており、サンドボックス化されています。

ページがユーザー向けにレンダリングされるときに、js sdkを使用してユーザー認証データを取得すると、ユーザーはすでにサーバー側の認証を受けているため、FB.getLoginStatusを使用できるはずです。
これで、クライアント側には、グラフAPIからユーザーデータを取得するために使用できるアクセストークンもあります。

2つのトークンは異なり、有効期限も異なりますが、それは問題ではありません。両方のトークンは、期待どおりに正しく機能するはずです。
双方が独自のトークンとAPIにリクエストを送信する方法を持っているため、両者間でfbデータを送信する必要はありません。

ですから、あなたが言及した3番目のオプションは、私にとっては最高のサウンドであり、それを実装するのも非常に簡単です。

編集

fb api全体がhttpリクエストで作成されるため、すべてのfacebookSDKはhttpリクエストの単なるラッパーです。
SDKを使用すると、URLを自分で作成し（さまざまな可能なパラメーターをすべて使用して）、要求を作成し、応答を解析することなく、データに簡単かつ短時間でアクセスできます。

正直なところ、C＃SDKがサーバー側の認証をサポートする方法を提供するのをやめるのは非常に悪い決断だと思います。
API全体を実装しないSDKを提供することのポイントは何ですか？

私の経験から、あなたの質問に対する最良の答えは、サーバー側とクライアント側の両方の認証を使用することです。C＃SDKはそれをサポートしていないため、独自のSDKを作成することをお勧めします。
まったく複雑ではありません。PythonとJava用に（2回）実装しました。可能なすべてのオプションをサポートするパブリックSDKとは異なり、独自のニーズに合わせて開発するため、正確なニーズに合わせて調整できます。

2回目の編集

完全に新しいSDKを作成する必要はありません。使用しているものを「拡張」し、サーバー側の認証サポートなど、必要な不足している部分を追加するだけです。

于 2012-05-31T10:51:42.720 に答える
0

言語固有かどうかはわかりませんが、サーバー側とクライアント側の両方の認証を使用しても害はありません。

オプション2で作業することはできますが、そうです、それもなりすましに対して脆弱になります。

オプション3を実行すると、そのユーザーセッションに単一のアクセストークンが割り当てられます。クライアント側からユーザー情報を渡すときに常になりすましの可能性があるため、これが最善の選択です。

于 2012-05-24T13:12:56.043 に答える
0

最近、まったく同じ質問がありました。オプション2です。Facebookブログからこの投稿を確認してください。

正直なところ、私はあなたがクッキーのUIDを偽装できるかどうかを知るのに十分なハッカーではありませんが、これはそれを行うための「公式の」方法のようです。

編集：オプション2の下にある他の質問に対して、はい、ドメインでこのCookieにアクセスする必要があると思います。

于 2012-05-29T15:29:38.330 に答える