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

Question

I have just recently run into an issue running an asp.net web app under visual studio 2008. I get the error \'type is not resolved for member...customUserPrincipal\'. Trac

Answer 1

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?

Answer 2

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.)

Answer 3

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).