I am building several WCF REST services in .NET 4.0 using the new WebServiceHostFactory classes.
The user needs to authenticate to the site using Forms Auth. That works as expected. The Csla.ApplicationContext.User has my custom principal.
When a call is made to the service instance, Csla.ApplicationContext.User is the GenericPrincipal and not my custom principal object. If I look at the HttpContext.Current.User from within the service code, it does have my custom principal object.
I'm using C#, CSLA 18.104.22.168, .NET 4.0 with SP1.
Any thoughts, guidance on what is happening and why?
I have some more information.
It looks like CSLA is creating an instance of ApplicationContextManager for the web application. I'm not sure if this is expected or not.
When the Forms Auth code runs and it sets the current user via Csla.ApplicationContext.User = MyPrincipal, the ApplicationContextManager instance is associating the custom principal with the current thread.
Now, that authentication has passed, the service is being created, and it is on a DIFFERENT thread.
Any ideas why this is happening? How can I fix it so that the user information is maintained correctly.
The authentication and service call are all on the same web server and in the same web application.
I have some more details.
I have my WCF Rest service configured for ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall). When I change to PerSession, the ApplicationContext.User has my custom principal.
So, why is my web app creating an instance of Csla.ApplicationContextManager and not Csla.Web.ApplicationContextManager?
Is there some other Csla configuration option I need to set to make Clsa.ApplicationContext create an instance of Csla.Web.ApplicationContextManager?
The ApplicationContext is designed to auto-detect the context manager to use based on the assemblies available at runtime. If your project references Csla.Web.dll then it should use the context manager from that assembly. If that assembly isn't in your \bin folder, obviously that type can't be used, so CSLA falls back to the smart client implementation.
Copyright (c) Marimer LLC