13

AuthenticateRequest イベント ハンドラー内で、スレッドのプリンシパルを設定しました。ここに私の IHttpModule の一部があります:

    public void Init(HttpApplication context)
    {
        context.AuthenticateRequest += AuthenticateRequest;
    }

    private void AuthenticateRequest(object sender, EventArgs e)
    {
        var principal = CreatePrincipal();
        HttpContext.Current.User = principal;
    }

しかし、System.Web にアクセスできないアセンブリがあるため、HttpContext.Current.User は使用できませんが、現在のプリンシパルにアクセスする必要があります。私の最初の考えは、私の方法を次のように変更することでした。

System.Threading.Thread.CurrentPrincipal = HttpContext.Current.User = principal;

必要に応じて Thread.CurrentPrincipal を使用します。

しかし、私が覚えている限り、複数のスレッドが同じリクエストを処理できるため、スレッドローカルストレージにリクエスト固有のものを保存することは安全ではないため、Thread.CurrentPrincipalと同じだと思います。か否か？

4

1 に答える 1

14

Jeff Moser の回答には同意しません。

標準の .NET 認証はすべて、Thread.CurrentPrincipal を使用して機能します。例えば：

PrincipalPermissionAttribute
PrincipalPermission.Demand

また、.NET RoleProvider を構成すると、.NETThread.CurrentPrincipalと同じプリンシパルに設定されHttpContext.Userます。

したがって、これは標準的な方法であり、カスタム認証コードで同じことを行います (または、カスタム RoleProvider として実装することをお勧めします)。

非同期 I/O については、このブログ投稿Thread.CurrentPrincipalに、カルチャ設定が自動的に新しいスレッドに渡されると記載されています。

ライブラリが承認目的でプリンシパルを使用Thread.CurrentPrincipalしている場合、信頼されていないコードはプリンシパルを引数として渡すことができますが、CAS はThread.CurrentPrincipal.

于 2013-10-30T14:10:23.243 に答える