Csla.Application.User set to UnauthenticatedPrincipal when using DataPortalProxy

[wilfreds]

Hi,

I'm in the process of converting from 4.5.601 to 5.5.2. It' WinForms, wcf, Custom CslaIdentity.

The program works fine when not using the proxy. But with the proxy the Csla.Application.User is lost and set to UnauthenticatedPrincipal after first use of the dataportal. In Csla 4.5.601 it also worked when using the proxy.

The reason for using a dataportal proxy is to have the ability to use multiple dataportals. Simply decorating a class like this:

[AppServer(ServerName = "ServerHK")]
[Serializable]
public class ButikkBestillingslisteBestilling : MyBusinessBase<ButikkBestillingslisteBestilling>
{

App.config may look like this:

<appSettings>
    <add key="CslaPropertyChangedMode" value="Windows" />
    <add key="CslaAuthentication" value="Csla" />
    <add key="ClientSettingsProvider.ServiceUri" value="" />

    <add key="CslaDataPortalProxy" value="CustomDataPortalProxy.SmartProxy, CustomDataPortalProxy" />
    <add key="ServerHK" value="http://MGButikkWcfAppServiceTest.service.mydomain.no/"/>
    <add key="ServerHK2" value="https://MGButikkWcfAppService.service.mydomain.no/"/>-->
</appSettings>

Here is the files in my CustomDataportalProxy:

namespace CustomDataportalProxy
{
  [AttributeUsage(AttributeTargets.Class)]
  public class AppServerAttribute : Attribute
  {
    public string ServerName { get; set; }
  }
}

using System;
using System.Configuration;
using Csla.Server;
using System.Threading.Tasks;
using System.IO;
#if !CSLA4_5
using Csla.Configuration;
#endif

namespace CustomDataportalProxy
{
    public class SmartProxy : Csla.DataPortalClient.IDataPortalProxy
    {
        // Sample url:  https://butikkdata.mydomain.no/MGButikkWcfAppService.v005/WcfPortal.svc

        public const string Version = "v008";
        public const string Portal = "WcfPortal.svc";

        private Csla.DataPortalClient.IDataPortalProxy GetProxy(Type objectType)
        {
            string serverName = null;
            var att = objectType.GetCustomAttributes(typeof(AppServerAttribute), false);
            if (att.Length > 0)
            {
                var asa = (AppServerAttribute)att[0];
                serverName = asa.ServerName;
            }
            var serverUrl = ConfigurationManager.AppSettings[serverName];
            if (serverUrl == null)
            {
                //Return LocalProxy if server not specified.
                return new Csla.DataPortalClient.LocalProxy();
            }
            else
            {
                if (serverUrl.Contains(Portal))
                {
                    //Probably dev environment. Don't rewrite url.
                    return new WcfProxy(serverUrl);
                }
                else
                {
                    serverUrl = serverUrl.TrimEnd(Path.DirectorySeparatorChar, Path.AltDirectorySeparatorChar);
                    return new WcfProxy(serverUrl + "." + Version + "/" + Portal);
                }
            }
        }

        public Task<DataPortalResult> Fetch(Type objectType, object criteria, DataPortalContext context, bool isSync)
        {
            return GetProxy(objectType).Fetch(objectType, criteria, context, isSync);
        }

        public Task<DataPortalResult> Update(object obj, DataPortalContext context, bool isSync)
        {
            return GetProxy(obj.GetType()).Update(obj, context, isSync);
        }

        public Task<DataPortalResult> Delete(Type objectType, object criteria, DataPortalContext context, bool isSync)
        {
            return GetProxy(objectType).Delete(objectType, criteria, context, isSync);
        }
    }
}

using System.ServiceModel;

namespace CustomDataportalProxy
{
    public class WcfProxy : Csla.DataPortalClient.WcfProxy
    {
        public WcfProxy(string serverUrl)
        {
            _serverUrl = serverUrl;
        }

        private string _serverUrl;

        protected override Csla.DataPortalClient.IWcfPortal GetProxy(ChannelFactory<Csla.DataPortalClient.IWcfPortal> cf)
        {
            return base.GetProxy(cf);
        }

        protected override ChannelFactory<Csla.DataPortalClient.IWcfPortal> GetChannelFactory()
        {
            //Trust all certificates
            System.Net.ServicePointManager.ServerCertificateValidationCallback =
                ((sender, certificate, chain, sslPolicyErrors) => true);

            // set up WSHttpBinding with 
            var binding = new WSHttpBinding()
            {
                SendTimeout = new System.TimeSpan(0, 2, 0),
                //MaxBufferPoolSize = int.MaxValue,       // default is 524288 and kept to default value
                MaxReceivedMessageSize = int.MaxValue,    // default is 65536
                ReaderQuotas = new System.Xml.XmlDictionaryReaderQuotas
                {
                    MaxArrayLength = int.MaxValue,          // default is 16384
                    MaxStringContentLength = int.MaxValue,  // default is 8192
                }
            };

            if (_serverUrl.ToUpper().Contains("HTTPS://"))
            {
                binding.Security.Mode = SecurityMode.Transport;
                binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
            }

            //string s = Csla.ApplicationContext.SerializationFormatter.ToString();

            ChannelFactory<Csla.DataPortalClient.IWcfPortal> cf;
            cf = new ChannelFactory<Csla.DataPortalClient.IWcfPortal>(binding, _serverUrl);
            return cf;
        }
    }
}

Any help is appreciated.

Best regards,
Wilfred

[rockfordlhotka]

Over time CSLA did change from defaulting to thread-local storage for current state to using AsyncLocal to store the state. This might be the source of your issue. At app startup you can switch the context manager to the older TLS implementation. This is done using the Csla.ApplicationContext.ContextManager property and setting it to an instance of Csla.Core.ApplicationContextManagerTls.

The other thing that we started changing in CSLA 5 is support for ClaimsPrincipal. Microsoft is phasing out our ability to use custom IPrincipal types, and it really looks like the only option going forward will be to use ClaimsPrincipal and ClaimsIdentity instances. I don't think any CSLA 5 changes to support these types are affecting you. I mention this so you can plan for the future.

Finally, you are probably aware that WCF has no future. Microsoft stopped supporting it and it doesn't exist in modern .NET. There is an open source project to recreate WCF for modern .NET, but I haven't followed closely to see how that is coming along. Again, not your immediate problem, but in planning for the future, you should expect to switch from WCF to Http.

[wilfreds]

Excellent! That worked. Happy about that.

Yes, will have to attend to WCF and ClaimsPrincipal also.