Open LL-SRN opened 4 months ago
Probably have to disable camel case conversion of variable names within the client.
Default options include camel-case conversion: https://github.com/graphql-dotnet/graphql-client/blob/master/src/GraphQL.Client.Serializer.SystemTextJson/SystemTextJsonSerializer.cs
That does sounds like a potential avenue of attack
EDIT - Am I getting this right:
The query object is of type string, so no conversion is done on the text of the query. In the string, the variable is called "$AWB"
The request object is, well, an object, so fields are camel-cased.
Meaning that the server receives an object like
{
"query":"query CustomsFields($AWB: String!) { shipments(filter: { shipment_awb: $AWB }) { ...",
"variables":{"awb":"some value"}
}
and then of course doesn't match awb
into $AWB
Right
I’m sure it’s configurable, but I don’t use this library. Maybe looking at some of the other issues / solutions will demonstrate how to configure the serializer.
I second the theory that this is the JSON serializer in the client serializing AWB
to Awb
or something...
To test this theory, your could:
awb
)AWB
and the corresponding value... this way it should keep the casing
Description
C# requires an exact match in variable names, despite this not being a requirement on the backend (or for e.g. requests made with POSTMAN)
Steps to reproduce
I don't have a publicly available endpoint for you to test this against, but the short version:
I get the expected result when I
POST
this:I get an error response when I
SendQueryAsync<>
this:The specific error response is:
If I change the variable name from
$AWB
to$shipment_awb
, the request succeeds with the same response as the raw post call.EXPECTED
Variable semantics are identical for calls made with REST and calls made with
SendQueryAsync
Actual
Variable semantics are not identical for etc./