0

クライアント側では、フラッシュ API を使用してサインインし、クライアントを認証しています

Facebook.init(MyFaceBooyKey, faceBookInit);

次に、フェイス ブックはクライアントに署名済みのリクエストなどを送り返します。

次に、クライアントはこの署名付きリクエストをサーバーに送信します。

サーバーで署名付きリクエストを処理すると、FaceBook ユーザー ID (UID) が表示されます

だから今私はそれを仮定しています：

有効な署名付きリクエストを送信したクライアントは、その中に含まれる Face book UID の所有者であり、クライアントはその UID のパスワードを知っている必要があり、facebook にログインしていますか?

このシステムは安全ですか?

ユーザークライアント側のFacebook認証を安全に使用して、2番目のサーバー、たとえばsepreak Facebookゲームサーバーに認証するにはどうすればよいですか。

署名された要求が Web 上で転送中に処理されず、Uiffrent UID でサーバーにログオンしているサードパーティから送信されたことを確認するにはどうすればよいですか?

すべてのフラッシュ ベースの Facebook ゲームでユーザーを認証する方法は?

また、デスクトップ アプリケーションを介した同じ本の認証では、署名済みの要求が送信されないことに注意してください。この場合、サーバーへの認証を行う方法は？

4

2 に答える 2

0

Facebookでの認証フローはすべてSLL（https）を使用するため、送信/取得するデータは保護されます。同じことがすべてのグラフAPIリクエストにも当てはまります。アクセストークンを含めながらhttpでAPIリクエストを作成しようとすると、次の応答が返されます。

{
   "error": {
      "message": "You must use https:// when passing an access token",
      "type": "OAuthException",
      "code": 1
   }
}

署名されたリクエストやアクセストークンをサーバーに送信する場合は、httpsでも送信する必要があります。そうすれば、通信も保護されます。

クライアント（そしてあなたがフラッシュクライアントを意味すると思います）はアクセストークン/署名されたリクエストの「所有者」ではなく、アプリは「所有者」です。

サーバー側でアクセストークンが必要な場合は、サーバー側の認証フローを使用して取得することをお勧めします。クライアント側でアクセストークンが必要な場合は、クライアント側の認証を使用できます。ユーザーはすでにアプリを承認し、（サーバー側のフローを通じて）確実に認証されているため、クライアント側のプロセスはユーザーには完全に表示されないはずです。そして最後に、クライアント側にもアクセストークンがあります（サーバーとは異なります）。

于 2012-04-19T16:32:29.380 に答える