マルチテナントMVC4Webアプリケーションを構築しています。URLエイリアス(customername.webapp.net)に基づいてテナントを区別します。顧客名を使用して検索できる顧客IDを格納するデータベースがあります。
明らかに、その顧客のユーザーが私のWebアプリを使用しているセッション全体で、この顧客IDが必要です。
この一意の識別子をセッションに保存することは許容されますか?それとも、この種の「セッションデータ」のより良い設計上の選択肢はありますか?
マルチテナントMVC4Webアプリケーションを構築しています。URLエイリアス(customername.webapp.net)に基づいてテナントを区別します。顧客名を使用して検索できる顧客IDを格納するデータベースがあります。
明らかに、その顧客のユーザーが私のWebアプリを使用しているセッション全体で、この顧客IDが必要です。
この一意の識別子をセッションに保存することは許容されますか?それとも、この種の「セッションデータ」のより良い設計上の選択肢はありますか?
この情報をフォーム認証 Cookie の UserData 部分に保存するか (Forms Authenticatoin を使用している場合)、またはclaims based authentication
. ユーザーがログインすると、現在のリクエストからテナント名を抽出し、データベースにクエリを実行してテナント ID を取得し、この ID を保持します。フォーム認証 Cookie の UserData 部分に ID を保存する[Authorize]
と、FormsAuthenticationTicket を読み取って復号化し、UserData 部分からテナント ID を取得して、カスタム プリンシパルを構築するカスタム属性を作成できます。このようにして、アプリケーションのどこでも使用できるようになります。クレーム ベースの認証を使用する場合は、それを新しいクレームとして追加するだけです。
アプリケーション内で Session をまったく使用しません。
答えに惑わされないでください。クッキーの使用は危険です。
この場合、Cookie ではなくセッションが有効なオプションになります。tenantId を Cookie 内に保存し、アプリケーションが Cookie に基づいてデータベース接続を確立する場合、ユーザーとしてログインした後、Cookie を改ざんおよび変更することができ、アプリケーションが別のデータベースに接続するため、セキュリティが低下します。Cookie が暗号化されていても、100% 信頼できるわけではありません。
この場合のセッションは、どのテナント データベースに接続する必要があるかを追跡する信頼できるサーバー情報になります。セッションは Cookie に比べてパフォーマンスが低下する可能性がありますが、この場合、他に適切なオプションはありません。あなたはマルチテナンシー アプリケーションを設計していますが、それは犠牲にしなければならないものです。
はい、本当に必要な場合は、引き続き Cookie を使用できる場合があります。ユーザーが何らかの方法で正しいデータベースに接続されているかどうかを確認し続ける必要があります。これは、セッションを使用するよりもパフォーマンスが低下します。
多くの人がセッションを悪用したり嫌ったりするからといって、セッションを嫌わないでください。正しい方法で使用するだけです。
結論として、セキュリティ目的で情報を使用している場合は、Cookie を使用しないでください。