Unable to read beyond the end of the stream.

[ajohnstone-ks]

I'm migrating to Csla 7 and have the latest version setup 7.0.4. We call a command to log the user in, which works and I set and id and key as claims into the ClaimsIdentity. We also store a Session object (a csla ROB) into the local context.

We then make a second call to refresh the login session (we have a readonlybase for the session data) since the user picks a point in an org hierarchy which affects their permissions. The call to this command works in local data portal mode, but in a remote configuration we get an error from Csla. The command just loads a new Session instance and returns it via a property, it doesn't do anything else. Also in the remote configuration, we never hit this command's Execute method, but the DataPortalController is returning a 200 response code. I'm not sure why its not hitting the execute. If I put the login code into another action method of the DataPortalController, everything is fine and both the login and session refresh commands execute, so I don't think its our code bombing anywhere.

Below is the exception stack trace I get back on the client.

   at System.IO.__Error.EndOfFile()
   at System.IO.BinaryReader.ReadString()
   at System.Security.Claims.Claim.Initialize(BinaryReader reader, ClaimsIdentity subject)
   at System.Security.Claims.ClaimsIdentity.Initialize(BinaryReader reader)
   at System.Security.Claims.ClaimsPrincipal.CreateClaimsIdentity(BinaryReader reader)
   at System.Security.Claims.ClaimsPrincipal.Initialize(BinaryReader reader)
   at Csla.Serialization.Mobile.MobileFormatter.DeserializeAsDTO(List`1 deserialized)
   at Csla.Serialization.Mobile.MobileFormatter.Csla.Serialization.ISerializationFormatter.Deserialize(Byte[] buffer)
   at Csla.Server.Hosts.HttpPortal.<Update>d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Csla.Server.Hosts.HttpPortalController.<CallPortal>d__11.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Csla.Server.Hosts.HttpPortalController.<InvokePortal>d__10.MoveNext()

This is our client configuration, which is part of the Setup in an NUnit test fixture.

ServiceCollection.AddCsla(
	x => {
		x.PropertyChangedMode(ApplicationContext.PropertyChangedModes.Windows);
		x.RegisterContextManager<Csla.Core.ApplicationContextManagerStatic>();

		x.DataPortal(
			y => {
				y
					.EnableSecurityPrincipalFlowFromClient()
					.AuthenticationType("CUSTOM")
					.AddServerSideDataPortal(
						z => {
							z.RegisterExceptionInspector<OutExceptionInspector>();
						}
					);
			}
		);
	}
);

And this is our configuration on the remote side, which is an Asp.Net MVC/WebApi 5 project on .net 4.7.2.

			services
				.AddCsla(x => {
					x.RegisterContextManager<Csla.Core.ApplicationContextManagerAsyncLocal>();
					x.DataPortal(
						y => {
							y
								.EnableSecurityPrincipalFlowFromClient()
								.AuthenticationType("CUSTOM")
								.AddServerSideDataPortal(
									z => {
										z.RegisterExceptionInspector<OutExceptionInspector>();
										z.RegisterAuthorizerProvider<OutDataPortalAuthorizer>();
									}
								);
						}
					);
				});

Anyone have any ideas what might be the issue? I'm also having trouble getting the symbols for Csla to load, which might help me figure out what's going on in Csla.

[rockfordlhotka]

I've never figured out how to get the CSLA symbols to load, so it isn't just you. It is an area where I'd sure welcome help!

The ClaimsPrincipal type isn't serializable, so MobileFormatter has a special case that detects a ClaimsPrincipal and wraps it in a CslaClaimsPrincipal, which is serializable.

Under the covers, the CslaClaimsPrincipal gets a byte[] from the actual ClaimsPrincipal, and that's what gets transferred over the wire.

On the other side, it should be creating a new ClaimsPrincipal based on that byte[] data.

Are you, by chance, still running on .NET Framework? It seems to me that there was once (and maybe still is) a bug in .NET Framework where ClaimsPrincipal couldn't deserialize itself from its own byte array.

[ajohnstone-ks]

@rockfordlhotka Yes, our app both client & server is running .net framework 4.7.2. If I am hitting that bug, any suggestions on how to proceed? Is there some place to plug-in to handle this ourselves? I just have an int and a long in the claims that needs to go to restore the server side session.

[ajohnstone-ks]

Well if I don't do anything with the principal and set it not to flow, but instead put the id/key in the ClientContext then that does seem to solve the exception I'm having.

Changing to Framework 4.8.1 didn't fix it, so I guess they never got around to fixing that bug. Thanks for your help, I'll think about how to move forward then!

[rockfordlhotka]

Hmm, so if it isn't fixed in 4.8 then I should probably try and figure out a workaround in MobileFormatter. I was rather hoping the issue would just "go away"...

[rockfordlhotka]

I have a potential implementation for MobileFormatter - noted in this issue: #1877

[ajohnstone-ks]

@rockfordlhotka I was thinking along those lines as well, since the claims are just strings.

For my purposes though I don't think there's any rush; rather than store the session id & key in the claimsidentity I'm just putting them into ClientContext and on the server looking for them there, so no mucking with the principal/identity at all for me anymore.