It looks like we have a nasty problem with ApplicationContext which I am hoping someone can help with.
We have some WCF services hosted within an ASP.NET website (where the website also contains ASPX pages) so that we can expose data to JavaScript for client-side functionality (such as auto-complete dropdowns.) All of the WCF services have AspNetCompatibility set to Required so that we can access Session contents. We're using IIS 7.5 to host the website and Csla 4.1 with .NET 4.
Csla.Web is in the \Bin folder so that we are using the HttpContext-based ApplicationContentManager.
Most of the time everything works just fine, but every once is a while our WCF services stop working. After patient debugging it appears that we end up with Csla.ApplicationContext.User returning the wrong principal (not our custom principal), so all of our authorisation then fails. This problem remains until we restart the AppDomain, when everything starts working normally again.
Having looked at the Csla implementation of ApplicationContext it is clear that the ContextManager property could cause us problems. It appears that on each request the IsValid property of the current IContextManager is checked and if IsValid returns false a new instance of the non-web ApplicationContextManager is created. In Csla.Web the ApplicationContextManager.IsValid property checks whether HttpContext.Current is null. If this were ever to happen then Csla would switch to the wrong ApplicationContextManager and this would not be corrected until the AppDomain restarts.
I have no idea why HttpContext.Current would ever be null, unless it is to do with the fact that we are using async service methods for some of our services to support best scalability. At the moment it is a guess that this is happening, because the problem doesn't occur regularly we have difficulty debugging it fully.
Has anyone else ever seen this problem and did they come up with a solution? Thanks.
Further to my previous post the developer who managed to recreate it whilst debugging found that after the WCF service started to fail the Csla.ApplicationContext.User result was different to HttpContext.Current.User. Csla.ApplicationContext.User returned an unauthenticated user with no roles whereas HttpContext.Current.User returned the custom principal with all of its roles as we would expect.
The only way I can see these two returning different values is if the wrong context manager is in use, and the only way I can see that changing through the life of the AppDomain is if, on the rare occasion, HttpContext.Current returns null and the code in the ContextManager property of the ApplicationContext class uses this to identify that it needs to create a new instance of the wrong context manager.
Hi,
This was fixed in CSLA 4.2.2
See: http://www.lhotka.net/cslabugs/edit_bug.aspx?id=944
And: Csla 4.2.2 Change Log
HttpContext.Current will be null when you execute code on a background thread. (ex BackgroundWorker)
Hi Jonny,
Thanks for your rapid response. That's very useful information and it looks like the code changes should ensure we don't run into this one again, or at least we would run into it only in sections of the code that run on background or custom threads and would not spread to change the behaviour of the AppDomain for the test of its lifetime.
We'll test out the new version and I'll verify the answer if it does indeed solve the problem - I can't see why it wouldn't, but time will tell.
Best wishes,
Andrew
Thanks Jonny, you were absolutely right. The problem is solved with the code in the later release.
I appreciate your time.
Andrew
Copyright (c) Marimer LLC