2

.NET3.5を使用してスマートクライアントアプリケーションを作成しています。WCFサービスを介して接続してSQLServer2008からデータを取得するWinformsクライアント。ユーザー名/パスワード（暗号化されたHTTPS経由）を渡して、次のような情報を返す必要があります。

  • このユーザー（電子メールアドレス）は現在のサブスクリプションの下にありますか
  • 後続のすべての呼び出しで次にどのサーバーに移動する必要があるか（貧乏人の負荷分散）
  • サブスクリプションなどに応じて異なるデータベースを使用する可能性があるため、接続文字列で使用するサーバー/データベース（資格情報は不要）。

したがって、サインオン時の最初の呼び出しは、ルックアップが実行される資格情報を送信します。シリアル化可能なクラスを使用して、有効期限、サーバー情報、データベース情報を返すトークンオブジェクト（これを処理する方法だと思います）を作成します。

問題は、後続のすべての呼び出しで、このトークンをすべてのサービスコントラクト（Webメソッド）にパラメーターとして渡すか、それとも現在のすべてのコントラクトをそのままにして、ヘッダーまたはその他のより一般的なメソッドでトークンを渡すことができるかということです。

私が説明するようなトークンシステムの実装をどのように提案しますか？

ありがとうございました

4

1 に答える 1

1

TokenID1つは、最初の「認証」呼び出しから、問題のユーザーとそのサブスクリプションを明確に識別するための一意のIDのみを返すことです。情報のセット全体を常に送受信する必要はありません。サーバー側のサービスのみがこれらの詳細を必要とするため、その情報をサーバーに残し、必要な場合にのみサーバーコードで参照できます。

そのため、最初の呼び出し（認証呼び出し）は、データベーステーブル、サブスクリプションテーブルに対して送信された資格情報をチェックし、その情報（どのサブスクリプションに基づいて誰が呼び出しているか）と、場合によっては何らかの有効期限を入力します。 / timeを「有効な呼び出し元」テーブルに入れ、そこからID（GUIDなど）を生成します。TokenIDの「寿命」を制限したい場合があります（たとえば、30分程度有効です）。これにより、最初の呼び出しが成功した後、ハイジャックされて永続的に使用されることがなくなります。その生成されたGUIDはTokenID、Authentication呼び出しからとして返され、後続の各呼び出しで識別子として使用できます。

使用するデータベースサーバーのようなものは、メッセージを行き来する場所が実際にはありません-サーバー側のサービスコードにとって厳密に重要です-そのままにしておいてください！

呼び出しの実際の値情報ではないこのような「メタ情報」をヘッダーに入れて、そこで検索することをお勧めします。WCFは、これを非常にうまく簡単にサポートします。クライアント側とサービス側のメッセージインスペクター（こことここのサンプル）、またはOperationContextScope（こことここのサンプルブログ投稿）を使用して、どちらも問題なく機能します。

于 2010-01-24T20:41:50.430 に答える