NewtonsoftJsonHubProtocol does not seem to respect setting for MaxDepth

[vlad-crisan]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I have a signalR application that sends complex objects between client and server, and I recently reached a case where the default MaxDepth of json deserialization is not sufficient.

My application is failing with:

Client disconnected. Connection Id:55dM9bnlnmLLNvlvgw05Tw. Exception: System.IO.InvalidDataException: Error reading JSON.
       ---> Newtonsoft.Json.JsonReaderException: The reader's MaxDepth of 64 has been exceeded. Path 'arguments[0].args.segment.children[9].children[1].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[7].children[0]', line 1, position 10348.
         at Newtonsoft.Json.JsonReader.Push(JsonContainerType value)
         at Newtonsoft.Json.JsonTextReader.ParseValue()
         at Newtonsoft.Json.Linq.JContainer.ReadContentFrom(JsonReader r, JsonLoadSettings settings)
         at Newtonsoft.Json.Linq.JContainer.ReadTokenFrom(JsonReader reader, JsonLoadSettings options)
         at Newtonsoft.Json.Linq.JArray.Load(JsonReader reader, JsonLoadSettings settings)
         at Microsoft.AspNetCore.SignalR.Protocol.NewtonsoftJsonHubProtocol.ParseMessage(Utf8BufferTextReader textReader, IInvocationBinder binder)
         --- End of inner exception stack trace ---
         at Microsoft.AspNetCore.SignalR.Protocol.NewtonsoftJsonHubProtocol.ParseMessage(Utf8BufferTextReader textReader, IInvocationBinder binder)
         at Microsoft.AspNetCore.SignalR.Protocol.NewtonsoftJsonHubProtocol.TryParseMessage(ReadOnlySequence`1& input, IInvocationBinder binder, HubMessage& message)
         at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.DispatchMessagesAsync(HubConnectionContext connection)
         at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.RunHubAsync(HubConnectionContext connection)

That is all fine, until I tried to set the value to a higher value, and was unsuccessful in doing so, and the error still complains about the max depth of 64.

I tried the following:

1. Using the "AddNewtonsoftJsonProtocol" extension method from Microsoft.Extensions.DependencyInjection.NewtonsoftJsonProtocolDependencyInjectionExtensions and setting options.PayloadSerializerSettings.MaxDepth to a higher value - this is not respected
2. Implementing IConfigureOptions in a custom class and setting options.PayloadSerializerSettings.MaxDepth to a higher value from inside the void Configure(NewtonsoftJsonHubProtocolOptions) method. Of course, also did the .ConfigureOptions on the IServiceCollection in ConfigureServices method of my Startup.cs
3. I also got desperate and tried to do JsonConvert.DefaultSettings = () => new JsonSerializerSettings { MaxDepth = 256 }; to use directly newtonsoft in the hope that it will respect the global default settings factory. Still no luck.

All my attempts ended up with the exact same error, complaining about the max depth of 64 being reached, and this causes my signalR connection to drop.

Please help with either providing the proper way to override that configuration, or help with a workaround (for example, is there a way to prevent signalR from deserializing my parameter, obtain somehow the raw content, and let my code handle the deserialization explicitly, in which case I can control the deserialization settings inline?

Looking at the code, in the NewtonsoftJsonHubProtocol method ParseMessage, when doing the JArray.Load it does indeed seem like the PayloadSerializer member is not used. Please evaluate if this is right. (there might be other places, not just JArray handling, but this is the one that is a match for my scenario, according to the stack trace too)

Thank you!

Expected Behavior

I expect to be able to change the value of MaxDepth used by the deserializer when handling the signalR messages so that I am not stuck with the default depth of 64 on the Newtonsoft Json protocol.

Steps To Reproduce

Set up a project with SignalR and NewtonsoftJsonProtocol.
Send a message from the client to the server with an object that has more than 64 levels of nesting. - expected to have it fail and disconnect.
Now try to change the MaxDepth configuration on the protocol - it will still fail with the same error - that the MaxDepth of 64 was reached

Exceptions (if any)

Client disconnected. Connection Id:55dM9bnlnmLLNvlvgw05Tw. Exception: System.IO.InvalidDataException: Error reading JSON.
       ---> Newtonsoft.Json.JsonReaderException: The reader's MaxDepth of 64 has been exceeded. Path 'arguments[0].args.segment.children[9].children[1].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[0].children[7].children[0]', line 1, position 10348.
         at Newtonsoft.Json.JsonReader.Push(JsonContainerType value)
         at Newtonsoft.Json.JsonTextReader.ParseValue()
         at Newtonsoft.Json.Linq.JContainer.ReadContentFrom(JsonReader r, JsonLoadSettings settings)
         at Newtonsoft.Json.Linq.JContainer.ReadTokenFrom(JsonReader reader, JsonLoadSettings options)
         at Newtonsoft.Json.Linq.JArray.Load(JsonReader reader, JsonLoadSettings settings)
         at Microsoft.AspNetCore.SignalR.Protocol.NewtonsoftJsonHubProtocol.ParseMessage(Utf8BufferTextReader textReader, IInvocationBinder binder)
         --- End of inner exception stack trace ---
         at Microsoft.AspNetCore.SignalR.Protocol.NewtonsoftJsonHubProtocol.ParseMessage(Utf8BufferTextReader textReader, IInvocationBinder binder)
         at Microsoft.AspNetCore.SignalR.Protocol.NewtonsoftJsonHubProtocol.TryParseMessage(ReadOnlySequence`1& input, IInvocationBinder binder, HubMessage& message)
         at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.DispatchMessagesAsync(HubConnectionContext connection)
         at Microsoft.AspNetCore.SignalR.HubConnectionHandler`1.RunHubAsync(HubConnectionContext connection)

.NET Version

7.0.401

Anything else?

No response

[BrennanConroy]

Unfortunately this looks like a gap in the Newtonsoft.Json library

Newtonsoft.Json.Linq.JArray.Load(JsonReader reader, JsonLoadSettings settings)

You can see that this uses a different settings type, and those settings don't have the option to specify depth. There is a recent issue opened on the Newtonsoft repo about the same problem: JamesNK/Newtonsoft.Json#2900

As for a workaround. If you send the object as a string then your hub method can accept the string and parse it itself. e.g. I assume you're using the javascript client: connection.send("method", JSON.stringify(myObj));

[vlad-crisan]

thank you @BrennanConroy for checking this out!
is there any workaround that does not involve changing the client-side, and handle it purely on the server-side?

I'm thinking as a parallel to how Http Controllers work, where it's possible to not have the body represented as a parameter, and access it explicitly through the Http Context and read it however we want as raw content.
Is there no such thing in SignalR? (basically to leave the server-side definition parameterless and try to obtain the values through different mechanics?)

[BrennanConroy]

workaround that does not involve changing the client-side, and handle it purely on the server-side?

Maybe. You could try accepting an object in the hub method. That would use the serializer in Newtonsoft.Json which might respect the max depth property since we'll pass your options in. Then you would manually need to parse your object out.

[vlad-crisan]

Maybe. You could try accepting an object in the hub method. That would use the serializer in Newtonsoft.Json which might respect the max depth property since we'll pass your options in. Then you would manually need to parse your object out.

That is how it's currently defined, and it goes through the failing flow described above.
Maybe it would work correctly with concrete types, but our commands are quite dynamic and all come through the same entry point in the backend. Would be quite an ordeal to convert all the possible commands to concrete contracts and unique method names.
Might try it out at some point though.

[Ibmurai]

We're hitting this problem too, and we'll have to do the string workaround.
It sucks :/