I've created a custom Principal and Identity modeled after PTTracker. We get the errors that Rocky described in his article (http://www.lhotka.net/weblog/CommentView,guid,cfcaf6c4-63cf-4cf1-8361-ed3db07496a4.aspx). (Very helpful article). But I noticed a way to apparently fix this problem (at least for our web apps) with just a minor code change. From the C# book on page 232:
public static IPrincipal User{
get{
if (HttpContext.Current == null) return Thread.CurrentPrincipal; else return HttpContext.Current.User;}
set{
if (HttpContext.Current != null) HttpContext.Current.User = value; Thread.CurrentPrincipal = value;}
}
I think the above set function is missing an ELSE. If I add this ELSE clause, the problem appears to be fixed.
set
{
if (HttpContext.Current != null) HttpContext.Current.User = value;else
Thread.CurrentPrincipal = value;
}
Is this a fix everyone can use; or am I unaware of other problems this will cause?
The problem would be that Thread.CurrentPrincipal should be the same as HttpContext. Most environment-neutral code uses Thread.CurrentPrincipal, because that's the recommended (and correct) approach.
So if you ever wanted to use a non-CSLA component of any sort, and that component cared about the current principal, it would fail because the thread wouldn't be set right.
Thanks for pointing out what I had missed.
I think I will proceed with my little change for a few weeks, at least until we get our custom Principal and Identity objects fairly stable. Then I will undo my change to Csla.ApplicationContext.User and put our Principal and Identity objects in the GAC.
Copyright (c) Marimer LLC