'http://ws.lhotka.net/WcfDataPortal/IWcfPortal/Fetch' is incorrect or because the message contains an invalid or expired security context token

ludwigs3rd posted on Monday, November 23, 2009

I just started using Command Objects and I'm getting the following exceptions. In one instance I'm using a command object to lazy load a field/property in a Business Object. I'd appreciate any suggestions anyone can offer.

InnerException = {"The message could not be processed. This is most likely because the action 'http://ws.lhotka.net/WcfDataPortal/IWcfPortal/Fetch' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch betwe...



Message = "An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail."



StackTrace = "\r\nServer stack trace: \r\n at System.ServiceModel.Security.SecuritySessionClientSettings`1.SecurityRequestSessionChannel.ProcessReply(Message reply, TimeSpan timeout, SecurityProtocolCorrelationState correlationState)\r\n at System.ServiceModel.Secur...

RockfordLhotka replied on Monday, November 23, 2009

Are you using any multithreading?

Your issue sure looks like a security issue - "security" is repeated numerous times in the exception text.

If you are using multithreading, it might be that the background thread doesn't have the correctly security tokens to call through WCF.

In any case, you are getting a WCF exception here, not a CSLA one. So that tells you that, on the server, WCF is rejecting your call before the call gets into CSLA - at least that narrows the issue to a WCF communication issue.

ludwigs3rd replied on Monday, November 23, 2009

Interesting points. So I'm using a DAL that was created using CodeSmith and they do implement a singleton instance on the DAL. However, I don't see anything pointing to multithreading. Any other ideas? Should this not be done?
In the business object all that is done is:
using (SafeDataReader reader = DataAccessLayer.Instance.MyDalMethod(etc...

This is at the top of the DAL:

public static DataAccessLayerBase Instance
{
get { return Nested.Current; }
}

private class Nested
{
static Nested()
{
Current = new DataAccessLayerBase();
}

///
/// Current singleton instance.
///
internal readonly static DataAccessLayerBase Current;
}

RockfordLhotka replied on Monday, November 23, 2009

In a multithreaded setting (like an app server) the DAL really can't be a singleton. ADO.NET itself is not threadsafe - including objects like connection, command and datareader. This means ADO.NET EF, LINQ to SQL, TableAdapter (all of which sit on top of ADO.NET) are not threadsafe.

In short, you really can't share your data access objects across threads - not just because CSLA doesn't support it, but because ADO.NET doesn't support it.

Or to flip that around - if ADO.NET actually worked across threads, I'm sure I'd have made the data portal work that way too. But since .NET doesn't support it, there's no point in CSLA supporting something you can't actually do.

RockfordLhotka replied on Monday, November 23, 2009

Sorry - that last post is probably not relevant...

Here's the thing. Your DAL code runs on the server. The exception you are getting is from WCF, and means that your server-side code is never invoked.

So it doesn't matter what your DAL does on the server, because you aren't getting past WCF.

My question was whether you are using multithreading on the client, or doing something else on the client that is causing a security failure when the client tries to call the service. Because that appears to be the nature of the exception you are getting - the client's WCF call is being rejected by the server for security reasons.

ludwigs3rd replied on Monday, November 23, 2009

Rocky, thanks so much for your prompt response. This is a show stopper and I'm trying to finish a project.

No multithreading is being done on the client. The wierd thing is that this started when I started using command objects. Security wise, are you saying there might be something I'm doing in the Identity or Principal class? I'm setting object level access on my BO's.

ludwigs3rd replied on Monday, November 23, 2009

Turned out [Serializable] wasn't set at the top of a class that inherited BusinessListBase. I know, 50 lashes with a wet noodle. There was another situation where I was running into the same error though using a command object in the Identity class. I'll apend this thread if I run into it again. Thanks Rocky!