Thread.CurrentPrincipal.Identity in ASP.NET - ist es sicher zu verwenden

Question

Innerhalb meiner AuthenticateRequest-Ereignishandler ich Thread-Prinzipal festlegen. Here'a ein Teil meines IHttpModule:

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

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

Aber ich habe eine Baugruppe, die keinen Zugriff auf System.Web haben sollte, so kann ich HttpContext.Current.User nicht verwenden, aber ich brauche, um aktuelle Prinzipal zugreifen. Mein allererster Gedanke war es, meine Methode zu ändern:

und verwenden Thread.CurrentPrincipal, wenn erforderlich.

Aber soweit ich mich erinnere, ist es nicht sicher, anforderungsspezifische Sachen in Thread Local Storage zu speichern, da mehrere Threads die gleiche Anfrage behandeln können, also denke ich, es ist das gleiche mit Thread.CurrentPrincipal. Oder nicht?

Answer 1

Ich stimme der Antwort von Jeff Moser nicht zu.

Der Standard-.NET-Autorisierungskram funktioniert mit Thread.CurrentPrincipal. z.B .:

PrincipalPermissionAttribute 
PrincipalPermission.Demand 

Auch, wenn Sie eine .NET-Roleprovider konfigurieren, wird es Thread.CurrentPrincipal auf dem gleichen Prinzip wie HttpContext.User gesetzt.

Daher ist dies der Standard Weg, und ich würde das gleiche tun in Ihrem benutzerdefinierten Authentifizierungscode (oder noch besser - implementieren Sie es als benutzerdefinierte RoleProvider).

Bei asynchroner E/A gibt this blog post an, dass Thread.CurrentPrincipal und Kultureinstellungen automatisch an den neuen Thread übergeben werden. Die Verwendung von ist vermutlich sicherer, wenn Ihre Bibliothek den Principal zu Autorisierungszwecken verwendet, da nicht vertrauenswürdiger Code in einem Principal als Argument übergeben werden kann, während CAS möglicherweise verhindern kann, dass gesetzt wird.