1

このようなプロジェクトに携わったことのある人は、おそらく次のサイトを知っているでしょう。

.NET を使用したモジュールの開発

この記事では、Mike Volodarsky が、IIS7 用の独自のセキュリティ認証拡張機能を作成する方法に関する非常に優れた投稿を作成しました。

私はこれを取り、自分の必要に応じて修正しました。基本的な認証資格情報を取得し、外部 Web サービスを呼び出して、別の Active Directory ドメインからユーザーを認証しています。

これは原則として、これまでのところうまく機能しています。

Web サービスの呼び出しには時間がかかり、要求、サイト、リソース (画像、スタイルシート、javascript ファイルなど) ごとに IIS7 がモジュールを呼び出して再度認証します。

IIS7 がこのモジュールをどのように処理するかはわからないので、有効期間が 10 分の SQL テーブル ベースのセキュリティ トークンを作成することにしました。したがって、私のコードは、このトークンが利用可能かどうかを確認してアクセスを許可するか、そうでない場合は Web サービスを呼び出して再度認証します。

私はすべてを開発しましたが、うまく機能します。本番環境では、タイムアウトが悪化し、SQL 接続に問題があることがわかりました。接続プールが過負荷になりました。プールサイズを非常に大きな数に設定するという悪い回避策でこれを修正しました。

ここに私の問題/質問があります:

このモジュールが何らかの方法でメモリにとどまり、メモリにトークンを保存できるかどうかは誰にもわかりません-アプリケーションプールスコープ? アイデアは、アプリケーションの実行中にトークンをメモリに保存することです。しかし、IIS7 でモジュールがどのように処理されるか、および私の考えが問題の解決策であるかどうかを調べるのに役立つ情報が見つかりません。

4

1 に答える 1

1

モジュール自体をメモリに保持することはありませんが、一般的なのは、暗号化された Cookie またはセッションを使用して資格情報を維持することです。ただし、問題を少し混同しているように聞こえます。あなたのモジュールは、カスタム認証モジュールではなく、カスタム メンバーシップ プロバイダーによって処理できる (そして処理する必要がある) ように思えます。

(あなたの投稿に基づいて) Web 経由で (表面上は Web フォームから) ユーザーのユーザー名とパスワードを取得していると仮定すると、ASP.NET でフォーム認証プロバイダーを使用してから、実際の処理を行うために customMembership プロバイダーを実装する必要があります。信用チェック。その後、Forms Atuh プロバイダーは、アプリとユーザーのブラウザー間の認証トークンの維持を処理できます。

于 2011-01-08T16:10:01.140 に答える