スキーマの分離によってデータの分離が実現されるマルチテナント アプリケーションを Azure で使用することを計画しています。
テナントの識別にサブドメインを使用する予定です。アイデアは、サブドメインからテナント名を取得し、ログイン ページからユーザー ID とパスワードを取得し、認証のために uid、pwd、およびテナント ID を検証することです。認証された場合、アプリケーションからの SPROCS へのすべての呼び出しは、スキーマ (テナントと同じ名前) に送信される必要があります。
ただし、テナントごとの接続文字列を web.config ファイルに保存したくありません。私が考えることができる1つのオプションは、スキーマ名とパスワードをログインページから受け入れられるテーブルに保存し、テナント固有の接続文字列を（そのUIDとパスワードで）作成してセッションに保存することです。ストアド プロシージャを初期化するときに、この接続文字列を使用します。
ただし、スキーマの uid とパスワードをセッションに保存することに熱心ではありません。このシナリオを管理する他の方法はありますか?
セッション値は Cookie に保存されないため、接続文字列をセッションに保存してもセキュリティ上の問題はありません。Cookie にはセッション ID のみが保存され、セッションの各値はセッション ID とともにサーバーに保存されます。
ただし、接続文字列は、テナントの場合、アプリケーションにアクセスするユーザーのグループに共通です。したがって、セッションに保存すると、より多くのメモリが使用されます。常にコンテキスト アプローチを使用するようにしてください。たとえば、データ層コードは次のように接続文字列を参照します。
文字列 con=AppContext.Current.ConnectionString;
上記の AppContext クラスには、ワーカー ロール、Web ロール、単体テストなど、ホストのタイプに基づいて接続文字列を取得するための実際のロジックがあります。
•接続文字列を web.config に保存でき、キーの前にサブドメイン値を付けることができます 例: Subdomain1_connection =接続文字列
•すべてのテナント情報が保存されている中央データベースがある場合は、それらをデータベースに保存できます
•そのようなDBがない場合は、テナント情報を格納するAzureテーブルを作成できます
マルチテナント アプリケーションには常に、AppContext と UserContext という 2 つのコンテキスト変数があり、この 2 つのコンテキストが適切なデータを提供します。したがって、私の単体テストはセッションを気にしません。コンテキストは、アプリが実行されている場所に基づいて、静的辞書またはセッションまたはデータベースまたは Azure テーブルから値を提供します。