ASP.net中的Thread.CurrentPrincipal.Identity - 可以安全使用

在我的AuthenticateRequest事件處理程序中，我設置了Thread的主體。 Here'a我的IHttpModule的一部分：ASP.net中的Thread.CurrentPrincipal.Identity - 可以安全使用

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 Local Storage中存儲請求特定的東西是不安全的，所以我想這與Thread.CurrentPrincipal是一樣的。或不？

來源

2013-10-30 dragonfly

聽起來好像你可以改變程序集 - 是不可能通過它需要的工作原理？ –

最近在類似的情況下，我只是強迫調用者提供主要對象。 – asawyer

這就是我要做的 - 注入本金。無論如何，我希望有更好的方法 – dragonfly

我不同意Jeff Moser的回答。

標準的.NET授權的東西都使用Thread.CurrentPrincipal。例如： -

PrincipalPermissionAttribute 
PrincipalPermission.Demand

另外，如果你配置一個.NET RoleProvider，它將設置Thread.CurrentPrincipal相同的本金HttpContext.User。

因此，這是執行此操作的標準方式，我會在自定義身份驗證代碼中執行相同的操作（甚至更好 - 將其作爲自定義RoleProvider實現）。

對於異步I/O，this blog post指出Thread.CurrentPrincipal和文化設置會自動傳遞到新線程。

使用Thread.CurrentPrincipal可以說是更安全的，如果您的庫使用委託人進行授權，因爲不可信代碼可以作爲參數傳遞給委託人，而CAS可能會阻止它設置Thread.CurrentPrincipal。

來源

2013-10-30 14:10:23 Joe

感謝您的鏈接！我沒有意識到ASP.NET爲你做到了這一點。我會刪除我的答案。 –

其實它是有道理的。我在整個應用程序中使用了像PrincipalPermission這樣的授權屬性，顯然這些屬性在幕後使用了Thread.CurrentPrincipal。非常感謝！ – dragonfly

ASP.net中的Thread.CurrentPrincipal.Identity - 可以安全使用

回答

相關問題