7

ASP.NET Web Api テンプレートを使用するサーバーを作成し、残りのサービスを実装しています。このサーバーは、ユーザーのハイスコア、進行状況、およびその他の情報を保存するモバイル ゲームのバックエンドになります。いくつかのアプローチ ( thisthis、およびthis ) を調べましたが、どのアプローチを使用するかを決めるのに苦労しています。私の場合、各ユーザー アカウントには (メール以外の) 限られた情報しか含まれないため、主にスコアの不正を防止したいと考えています。理想的には次のようになります。

  1. ユーザーが初めてアプリを開く
  2. ユーザーにはカスタムユーザー名のオプションが与えられ、これはサーバーによってチェックされるため、重複はありません
  3. ユーザーには、ランダムに生成された 6 桁の PIN 番号が与えられます (異なる電話で同じアカウントを使用できるようにするため)。
  4. ユーザーがメールアドレスを入力
  5. 新しいユーザーがサーバーに作成されます (サーバーは、アカウントがクライアント アプリケーションの有効なインスタンスによって作成されたことを確認します)
  6. ユーザーがゲームをプレイし、結果をアップロードします (基本認証経由? )
  7. ユーザーはグローバルな結果を表示できます (ユーザー固有ではない GET メソッドにセキュリティはありません)

どのタイプの認証 (ブラウザのログイン画面を使用しないなど) と認証方法を使用するかを絞り込むのに苦労しています。どんな助けでも大歓迎です。

-タマス

4

2 に答える 2

5

基本認証を使用している場合でも、HTTPSを使用することをお勧めします。HTTPSを使用している場合は、クライアント証明書を使用してクライアントを検証することもできます。有効な証明書を持つクライアントのみがアクセスを許可されます。このAPIを他のコンシューマーに公開しておらず、自分で開発したクライアントによってのみ使用される場合は、WS-SecurityとWCFを検討することをお勧めします。ここには、ネイキッドのオートバイドライバーを比喩として使用した違いについての面白い説明があります

于 2012-04-10T19:32:57.637 に答える
1

異なるクライアント/デバイスからのものである場合、トークンベースの認証のようなものがうまくいくかもしれません。

アイデアは単純です。Web サービスに認証メソッドがあります。このメソッドは、資格情報の確認と「トークン」の発行を担当します。以降のすべてのクライアント呼び出しで使用される SHA1 または MD5 文字列のようないくつかの単純な構造。

クライアントが認証されると、セッションの全期間にわたってトークンが保存されます。SaveScore などの残りの Web サービス メソッドは、トークンをパラメーターとして受け入れるだけです。次に、それが有効かどうかを確認する責任があります。トークンが有効でない場合、呼び出しは処理されていません。

于 2012-04-10T19:15:06.163 に答える