-
Notifications
You must be signed in to change notification settings - Fork 133
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Variable parsing different between C# "GraphQLRequest" and json/webui #648
Comments
Probably have to disable camel case conversion of variable names within the client. |
Default options include camel-case conversion: |
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 |
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 To test this theory, your could:
|
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./
The text was updated successfully, but these errors were encountered: