difference between http.context.user and thread.currentprincipal and when to use them?

I have just recently run into an issue running an asp.net web app under visual studio 2008. I get the er开发者_开发知识库ror 'type is not resolved for member...customUserPrincipal'. Tracking down various discussion groups it seems that there is an issue with Visual Studio's web server when you assign a custom principal against the Thread.CurrentPrincipal.

In my code, I now use...

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

I'm glad that I got the error out of the way, but it begs the question "What is the difference between these two methods of setting a principal?". There are other stackoverflow questions related to the differences but they don't get into the details of the two approaches.

I did find one tantalizing post that had the following grandiose comment but no explanation to back up his assertions...

Use HttpConext.Current.User for all web (ASPX/ASMX) applications.

Use Thread.CurrentPrincipal for all other applications like winForms, console and windows service applications.

Can any of you security/dot.net gurus shed some light on this subject?

The first thing that the HttpApplication object does when it acquires a thread is to set the thread's principal to the HttpContext's principal. This syncs up the principals.

If, however, you go and set the Thread's principal later on, the HttpApplication internally still has a different principal set for the user context. This is why you should always set it through the HttpContext.

(If you take a look in Reflector, you can see the complex code that runs when you do a "set" on HttpContext.User - it does a lot of internal stuff with IIS to properly set the principal.)

Under a webforms application I believe Thread.CurrentPrincipal will be the principal for whomever is running the worker process (Thread).

HttpContext.Current.User will be the current logged in web-user.

In the case of a forms/wpf app it makes sense because the user you're running the application under is the one you're interested in.

Are you trying to masquerade the worker process or the logged in user?

Does this article explain it?

http://www.hanselman.com/blog/CommentView.aspx?guid=22c42b73-4004-40ce-8af9-47f1b9b434ed

Here's an excerpt:

I have some code in an ASP.NET custom FormsAuthentication Login that looks something like this:

// 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;

It is called on the Global.asax's AuthenticateRequest so everything is all setup before the Page's events fire. It provides a custom IPrincipal that integrates our eFinance Server with ASP.NET. It's quite a lovely subsystem, IMHO.

Other operations count on being able to get this 'Call Context' IPrincipal from the current thread at any time. In another section of code someone was doing this in the MIDDLE of the HttpRequest (somewhere in the Page_Load) after having JUST called the routine above for the first time:

return Thread.CurrentPrincipal as VoyagerPrincipal;

In the instance where someone calls the first chunk of code then expects to be able to call the second chunk within the same HttpRequest, the Thread.CurrentPrincipal contains a GenericPrincipal populated much earlier by the HttpApplication. (Or a WindowsPrincipal, depending on your settings).