Need help getting started with GRPC dataportal

[b-higginbotham]

Hey folks,

I am working on a project that is still using a very old version of CSLA and I am researching a path forward for upgrading to the latest version. As a part of this effort, I am trying to build a basic GRPC data portal client/server proof of concept. I have a server project, a client project, and a business library with a single object. I've tried multiple configurations, but I always end up with the same error message during my tests.
Csla.DataPortalException: 'The server side portal could not deserialize the incoming request stream.'

I have based my implementation on the SimpleNTier sample and the guidance provided in #2428. I'm sure I am missing something simple with configuration but I am not having any luck figuring it out on my own or searching for other examples. I'll provide all of the code for my proof of concept project.

DataPortalServer - Program.cs

using Csla.Channels.Grpc;
using Csla.Configuration;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddGrpc();
builder.Services.AddCsla();

var app = builder.Build();
app.UseRouting();
app.MapGrpcService<GrpcPortal>();
app.Run();

BusinessLibrary - Person.cs

using Csla;
using Csla.Server;

namespace BusinessLibrary
{
    [ObjectFactory(typeof(PersonFactory))]
    [CslaImplementProperties]
    public partial class Person : BusinessBase<Person>
    {
        public partial int Id { get; set; }
        public partial string Name { get; set; }
    }
}

BusinessLibrary - PersonFactory.cs

using Csla;
using Csla.Server;

namespace BusinessLibrary
{
    public class PersonFactory(ApplicationContext applicationContext) : ObjectFactory(applicationContext)
    {
        public Person Fetch(int id)
        {
            var person = ApplicationContext.CreateInstanceDI<Person>();
            using (BypassPropertyChecks(person))
            {
                person.Id = id;
                person.Name = "Clark Kent";
            }
            MarkOld(person);
            return person;
        }
    }
}

DataPortalClient - Program.cs

using BusinessLibrary;
using Csla;
using Csla.Configuration;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();
services
    .AddCsla(csla => csla
    .DataPortal(dp => dp
    .AddClientSideDataPortal(c => c
    .UseGrpcProxy(grpc => grpc
    .DataPortalUrl = "http://localhost/grpc/dataportal"))));

var provider = services.BuildServiceProvider();
var applicationContext = provider.GetRequiredService<ApplicationContext>();
var portal = applicationContext.GetRequiredService<IDataPortal<Person>>();

int personId = 1;
// Deserialization exception occurs here.
var p = portal.Fetch(personId);

Console.WriteLine(p.Name);
Console.ReadLine();

Any help will be greatly appreciated.

[b-higginbotham]

After some further investigation, this issue seems to be specific to CSLA 10. My projects are targeting .net 9.0 because I do not currently have access to .net 10 for reasons beyond my control. This issue may simply be a backwards compatibility issue between CSLA 10 and .net 9.0. Downgrading the CSLA package references to 9.1.1 has allowed me to move forward.

[Chicagoan2016]

@b-higginbotham Thanks for sharing. I am going to try your code. We have a project that could benefit from gRPC dataportal.

[rockfordlhotka]

The client and server always need to run the same version of CSLA and the same version of your code.

It is quite possible that they need the same version of .NET as well.

[b-higginbotham]

Well, I have determined that GRPC will not be a viable option for my project at this time. However, I am still encountering this problem using my own custom channel that I am currently building. I based my code off of Csla.Channels.Grpc.GrpcPortal, and thus I have accidentally recreated the same problem.

The issue is with the creation of the DataPortalContext objects in the Create, Delete, Fetch, and Update methods in the GrpcPortal class.

Here is the code from the v9.x branch:

var context = new DataPortalContext(
          _applicationContext, (IPrincipal)_applicationContext.GetRequiredService<ISerializationFormatter>().Deserialize(request.Principal),
          true,
          request.ClientCulture,
          request.ClientUICulture,
          (IContextDictionary)_applicationContext.GetRequiredService<ISerializationFormatter>().Deserialize(request.ClientContext));

And here is the code from the main branch:

var context = new DataPortalContext(
          _applicationContext, Deserialize<IPrincipal>(request.Principal),
          true,
          request.ClientCulture,
          request.ClientUICulture,
          Deserialize<IContextDictionary>(request.ClientContext));

The main branch calls the new Deserialize<T> method which looks like this:

private T Deserialize<T>(byte[] data)
    {
      var deserializedData = _applicationContext.GetRequiredService<ISerializationFormatter>().Deserialize(data) ?? throw new SerializationException(Resources.ServerSideDataPortalRequestDeserializationFailed);
      if (deserializedData is not T castedData)
      {
        throw new SerializationException(string.Format(Resources.DeserializationFailedDueToWrongData, typeof(T).FullName));
      }

      return castedData;
    }

The error is occurring when attempting to deserialize the IPrincipal object from the request.Principal property.

In Upgrading to CSLA 10.md there is a line that notes:

• The User and Principal properties of ApplicationContext no longer return null

On the client side, I can see that this is accurate. applicationContext.User returns an instance of System.Security.Claims.ClaimsPrincipal, as expected. However, when attempting to deserialize the principal from the data portal request on the server side, the deserialized object is null which causes the exception to be thrown by the first line of the new Deserialize<T> method.

Am I missing some configuration for my client and/or server or is this a bug in the GRPC channel?

To provide some clarity regarding previous responses:

• The client, server, and business library examples provided above are all referencing CSLA version 10.0.0.
• The client, server, and business library examples above are all targeting net9.0 for their target framework.

[b-higginbotham]

One further observation after looking at the integration tests:

It appears that null is a valid value for the DataPortalContext constructor. The principal argument is specified as IPrincipal? and the integrations tests pass null to the constructor.

I believe this exception being thrown during deserialization is a bug.

[rockfordlhotka]

Here's an extremely simple demo using the grpc data portal channel:

https://github.com/rockfordlhotka/CslaGrpc

[b-higginbotham]

Did you run it?

[rockfordlhotka]

● It works. All three data portal operations completed successfully over gRPC:

  1. CreateAsync - Created a new PersonEdit and set FirstName/LastName → Created: Test User
  2. FetchAsync - Fetched PersonEdit with id=1 from the server → Got: John Doe (Id=1)
  3. UpdateAsync (Insert) - Saved the new person back through the data portal → Saved: Test User

  Let me also check what the server logged.

● Task Output(non-blocking) bgwikxlc1
  ⎿  CslaGrpc server listening on http://localhost:5001
     info: Microsoft.Hosting.Lifetime[14]
           Now listening on: http://localhost:5001
     … +7 lines (ctrl+o to expand)

● The server side confirms it received and processed the Insert call: [PersonEdit] Insert called for Test User.

  The CSLA gRPC data portal channel is working correctly. The client console app successfully communicates with the server console app over gRPC (HTTP/2 on
  localhost:5001), and all data portal operations (Create, Fetch, Insert/Save) execute as expected.

[rockfordlhotka]

I asked claude to try and get the sort of failure you are seeing, and it is almost certainly this:

  Yes, they almost certainly have FlowSecurityPrincipalFromClient = true in their CSLA configuration.

  The relevant setting is on Csla.Configuration.SecurityOptions:

  ┌─────────────────────────────────┬────────┬─────────┐
  │            Property             │  Type  │ Default │
  ├─────────────────────────────────┼────────┼─────────┤
  │ FlowSecurityPrincipalFromClient │ bool   │ false   │
  ├─────────────────────────────────┼────────┼─────────┤
  │ AuthenticationType              │ string │ "Csla"  │
  └─────────────────────────────────┴────────┴─────────┘

  How it's configured:
  services.AddCsla(o => o
      .Security(s => s.FlowSecurityPrincipalFromClient = true)  // <-- this causes it
      ...
  );

  What happens when enabled:

  I reproduced it. When FlowSecurityPrincipalFromClient = true, the client serializes the current IPrincipal and sends it through the gRPC channel. If no principal has
  been set (which is the default in a console app), a null principal gets serialized and sent across. On the server side, DataPortal.SetPrincipal() in SetContext()
  tries to process that incoming principal and fails with:

  ▎ Csla.Security.SecurityException: No principal object should be passed to DataPortal when using Windows integrated security

  The "null principal deserialization" issue the user is reporting is this same code path — the principal value flowing through the channel is null/empty, and the
  server-side deserialization of it fails.

  The fix is one of:

  1. Remove/don't set FlowSecurityPrincipalFromClient = true (the default false works fine — we proved it above)
  2. If they need to flow the principal, they must ensure both sides have matching AuthenticationType = "Csla" and the client has a properly serializable
  Csla.Security.CslaClaimsPrincipal set before making data portal calls

[streagan123]

@rockfordlhotka The issue I'm seeing testing this is the solution won't even build. It looks to be using some pre-release version of CSLA that is not available (10.1.0-gca5b9ee40a). I downgraded those to CSLA 10.0.0 and added a reference to Csla.Channels.Grpc 10.0.0 to get the solution to build. When running that, the same serialization error is observed.

I see the input from Claude, but this error is running the sample project that you provided and FlowSecurityPrincipalFromClient is not anywhere in there.

Any thoughts?

[b-higginbotham]

The Claude analysis is only halfway correct. The problem with AI is that it behaves just like a toddler when it doesn't actually know the right answer to something -- it just makes up nonsense.

You can clearly see in my original post that the .Security(s => s.FlowSecurityPrincipalFromClient = true) setting is not being used. It is left at the default setting. When testing with that setting enabled, I do, in fact, get the same error that Claude reproduced which is Csla.DataPortalException: 'DataPortal.Fetch failed on the server' on the client and Csla.Server.DataPortalException: DataPortal.Fetch failed on the server ---> Csla.Security.SecurityException: No principal object should be passed to DataPortal when using Windows integrated security on the server. However, this error is completely different from the original error that I posted which was Csla.DataPortalException: 'The server side portal could not deserialize the incoming request stream.'

Ironically, the setting that Claude is blaming this error on actually solved the original problem that I reported. To be more specific, the example I gave in my original post fails here:

csla/Source/Csla.Channels.Grpc/GrpcPortal.cs

Line 210 in 8884382

_applicationContext, Deserialize<IPrincipal>(request.Principal),

while the example from the Claude test fails here:

csla/Source/Csla.Channels.Grpc/GrpcPortal.cs

Line 217 in 8884382

var dpr = await dataPortalServer.Fetch(objectType, criteria, context, true);

Here are some pictures to hopefully better illustrate what is happening.

It's possible that you have changes that fix this issue in the Csla version 10.1.0-gca5b9ee40a package that your sample references, however, that prerelease version is not available on nuget.org and I don't know where else to look for it. So my only option was to downgrade the version to Csla 10.0.0 which is what is publicly available and with that version, I get the same error from my original post when pulling and running the sample repo that you provided.

Another possibility that I guess we need to consider is the environment. I am testing this in Windows 11 version 23H2 build 22631.6783 using .net 9.0 and Visual Studio 17.14.27.

I am still convinced that this behavior is probably due to a bug. The data portal throws an exception that explicitly states that a client principal object should not be passed to the data portal when using Windows integrated security if you enable FlowSecurityPrincipalFromClient. This tells me that the portal receiving a null IPrincipal object from the request is correct and expected behavior in this situation. However, the part that is incorrect, is that the Deserialize method explicitly throws an exception when attempting to deserialize any null value, even when null is a valid value for the calling code.

[b-higginbotham]

Also, when poking to find other areas where this issue may exist, I noticed that the Rabbit MQ portal has the same problem as the GRPC portal because it has the exact same Deserialize method that is called in the same way.

However, the issue has been correctly addressed by the code in the HTTP portal which instead has two distinct methods for deserialization:

    private T? Deserialize<T>(byte[] data)
    {
      var deserializedData = _applicationContext.GetRequiredService<ISerializationFormatter>().Deserialize(data);
      return (T?)deserializedData;
    }

    private T DeserializeRequired<T>(byte[] data)
    {
      return Deserialize<T>(data) ?? throw new SerializationException(Resources.ServerSideDataPortalRequestDeserializationFailed);
    }

My recommendation would be to change the GRPC portal and the Rabbit MQ portal to match the deserialization behavior of the HTTP portal.

[rockfordlhotka]

Does your PR resolve your issue?

[b-higginbotham]

Yes it does.