Scott Hanselman

Warning: I find this fascinating and amazing as a caused a suble bug and was generally bizarre today.  You likely don't care. :)

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

Assuming, of course that the Thread's CurrentPrincipal is that same Principal.  And 99.999% percent of the time it is, except when it isn't at all.

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

• When the first chunk of code runs in the Global.asax's AuthenticateRequest these two properties ARE in fact the same object
• When the first chunk of code runs in the context of a Page (read: later!) these properties are NOT the same object.

Why? Reflector tells us in the HttpApplication's internal OnThreadEnter:

internal void OnThreadEnter()
{
      this._savedContext = HttpContextWrapper.SwitchContext(this._context);
      this._context.Impersonation.Start(false, true);
      HttpRuntime.RequestTimeoutManager.Add(this._context);
      this.SetPrincipalOnThread(this._context.User);
      this.SetCulture(false);
}

internal void SetPrincipalOnThread(IPrincipal principal)
{
      if (!this._restorePrincipal)
      {
            this._restorePrincipal = true;
            this._savedPrincipal = Thread.CurrentPrincipal;
      }
      Thread.CurrentPrincipal = principal;
}

I had assumed, wrongly, that these two objects were coming from the same object reference always.  In fact, they are early on, but you can (as I did) change one without changing the other.  So, the first chunk of code becomes 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;

// Make sure the Principal's are in sync
System.Threading.Thread.CurrentPrincipal = System.Web.HttpContext.Current.User;

And all is right with my world, and the folks can continue to get the expected behavior when doing a "mid-page" FormAuthentication login.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About   Newsletter

Hosting By