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

asp.net security

Question

Acabo de encontrar un problema al ejecutar una aplicación web de asp.net en Visual Studio 2008. Recibo el error "el tipo no se resuelve para el miembro ... customUserPrincipal". Al rastrear varios grupos de discusión, parece que hay un problema con el servidor web de Visual Studio cuando asigna un principal personalizado contra Thread.CurrentPrincipal.

En mi código, ahora uso ...

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

Me alegro de haber eliminado el error, pero me surge la pregunta "¿Cuál es la diferencia entre estos dos métodos para establecer un principal?". Hay otras questions stackoverflow relacionadas con las diferencias, pero no entran en los detalles de los dos enfoques.

Encontré una publicación tentadora que tenía el siguiente comentario grandioso, pero ninguna explicación para respaldar sus afirmaciones ...

Use HttpConext.Current.User para todas las aplicaciones web (ASPX / ASMX).

Use Thread.CurrentPrincipal para todas las demás aplicaciones como winForms, consola y aplicaciones de servicio de Windows.

¿Puede alguno de ustedes gurús de la seguridad / dot.net arrojar algo de luz sobre este tema?

Answer 1

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

Aquí hay un extracto:

Tengo algo de código en un inicio de sesión de autenticación de formularios personalizado de ASP.NET que se parece a 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;

Llamó a AuthenticateRequest de Global.asax para que todo esté configurado antes de que se activen los eventos de la Página. Proporciona un IPrincipal personalizado que integra nuestro servidor de eFinance con ASP.NET. Es un subsistema bastante bonito, en mi humilde opinión.

Otras operaciones cuentan con la posibilidad de obtener este IPrincipal de ''Contexto de llamada'' del hilo actual en cualquier momento. En otra sección del código, alguien estaba haciendo esto en el MEDIO de la HttpRequest (en algún lugar de la Carga de la Página) después de haber JUSTADO haber llamado la rutina anterior por primera vez:

return Thread.CurrentPrincipal as VoyagerPrincipal;

En el caso de que alguien llame a la primera parte del código y luego espere poder llamar a la segunda parte dentro de la misma HttpRequest, Thread.CurrentPrincipal contiene una GenericPrincipal que se completó mucho antes con la aplicación HttpApplication. (O un WindowsPrincipal, dependiendo de su configuración).

Answer 2

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

HttpContext.Current.User será el usuario web registrado actualmente.

En el caso de una aplicación forms / wpf tiene sentido porque el usuario en el que está ejecutando la aplicación es el que le interesa.

¿Está intentando enmascarar el proceso de trabajo o el usuario que ha iniciado sesión?

Answer 3

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

Sin embargo, si va y configura el principio del subproceso más adelante, la aplicación HttpApplication internamente todavía tiene un conjunto principal diferente para el contexto del usuario. Esta es la razón por la que siempre debe configurarlo a través de HttpContext.

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