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

Recientemente me encontré con un problema al ejecutar una aplicación web asp.net en Visual Studio 2008. Obtuve el error “el tipo no está resuelto para el miembro … 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 de haber solucionado el error, pero me plantea la pregunta “¿Cuál es la diferencia entre estos dos métodos de establecer un principal?”. Hay otras preguntas de stackoverflow relacionadas con las diferencias, pero no llegan a 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 los gurús de seguridad / dot.net arrojar algo de luz sobre este tema?

En 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 conectado actualmente.

En el caso de una aplicación forms / wpf, tiene sentido porque el usuario al que ejecuta la aplicación es el que le interesa.

¿Estás tratando de enmascarar el proceso de trabajo o el usuario conectado?

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.

Sin embargo, si vas y configuras el principal del Thread más adelante, la aplicación Http 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.)

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

Aquí hay un extracto:

Tengo un código en un inicio de sesión FormsAuthentication personalizado de ASP.NET que se ve así:

 // 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 eFinance con ASP.NET. Es un subsistema bastante encantador, en mi humilde opinión.

Otras operaciones cuentan con la posibilidad de obtener este IPrincipal ‘Call Context’ del hilo actual en cualquier momento. En otra sección del código, alguien estaba haciendo esto en el MEDIO de HttpRequest (en algún lugar de Page_Load) después de haber SOLO llamado a la rutina anterior por primera vez:

 return Thread.CurrentPrincipal as VoyagerPrincipal; 

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