diferencia entre http.context.user y thread.currentprincipal y cuándo usarlos?

Question

Recientemente me encontré con un problema al ejecutar una aplicación web asp.net en Visual Studio 2008. Recibo el error 'type not resolved for member ... customUserPrincipal'. Al rastrear varios grupos de discusión, parece que hay un problema con el servidor web de Visual Studio cuando se asigna un principal personalizado contra Thread.CurrentPrincipal.

En mi código, ahora uso ...

HttpContext.Current.User = myCustomPrincipal 
//Thread.CurrentPrincipal = myCustomPrincipal 

Me alegro que me dieron el error fuera del camino, pero se plantea la pregunta "¿Cuál es la diferencia entre estos dos métodos de establecer un principal? ". Hay otros Stackoverflow questions relacionados con las diferencias, pero no entran en los detalles de los dos enfoques.

Lo que encontrar una tentadora post que tenía el siguiente comentario grandioso pero ninguna explicación para respaldar sus afirmaciones ...

Uso HttpConext.Current.User para todos aplicaciones web (ASPX/ASMX).

Uso Thread.CurrentPrincipal para todas las demás aplicaciones como WinForms, consola y servicio de las ventanas aplicaciones.

¿Alguno de ustedes gurus de seguridad/dot.net arroja algo de luz sobre este tema?

Answer 1

Bajo una aplicación webforms creo que Thread.CurrentPrincipal será el principal para quien esté ejecutando el proceso de trabajo (Subproceso).

HttpContext.Current.User será el usuario actual con sesión iniciada.

En el caso de una aplicación de formularios/WPF tiene sentido porque el usuario se está ejecutando la aplicación bajo es el que le interesa.

¿Estás tratando de hacerse pasar el proceso de trabajo o que ha iniciado sesión en usuario?

Answer 2

¿Explica este artículo?
http://www.hanselman.com/blog/CommentView.aspx?guid=22c42b73-4004-40ce-8af9-47f1b9b434ed

He aquí un extracto:

tengo algo de código en una costumbre ASP.NET FormsAuthentication inicio de sesión que se ve algo como esto:

// This principal will flow throughout the request. 
VoyagerPrincipal principal = new VoyagerPrincipal(yada, yada, yada); 

// Attach the new principal object to the current HttpContext object 
HttpContext.Current.User = principal; 

Se pide a la global. El AuthenticateRequest de asax así que todo es todo configurado antes de que se active el evento de la página. Proporciona un IPrincipal personalizado que integra nuestro servidor eFinance con ASP.NET. Es un subsistema bastante encantador, en mi humilde opinión.

Otras operaciones cuentan con la posibilidad de obtener este 'Call Context' IPrincipal del hilo actual en cualquier momento.En otra sección de código que alguien estaba haciendo esto en el medio de la HttpRequest (en algún lugar en el Load) después de haber llamado sólo la rutina de arriba por primera vez:

return Thread.CurrentPrincipal as VoyagerPrincipal; 

En el caso de que alguien llama a la primer trozo de código, entonces espera poder llamar al segundo fragmento dentro de la misma HttpRequest , el Thread.CurrentPrincipal contiene un GenericPrincipal poblado mucho antes por HttpApplication. (O un WindowsPrincipal, dependiendo de su configuración).

Answer 3

Lo primero que hace el objeto HttpApplication cuando adquiere un hilo es establecer el principal del hilo en el principal de HttpContext. Esto sincroniza los principales.

Si, sin embargo, va y establece el principal del subproceso más adelante, la aplicación Http internamente todavía tiene un conjunto principal diferente para el contexto del usuario. Esta es la razón por la que siempre debe establecerlo a través del HttpContext.

(Si echas un vistazo a Reflector, puedes ver el código complejo que se ejecuta cuando haces un "conjunto" en HttpContext.User - hace un montón de cosas internas con IIS para establecer correctamente el principal.)