JSON String Header in UDG : Tyk Cloud

Support
#1

Hi everybody

I am using tyk cloud and setting up graphql UDG. In order to setup one data source (external rest) I need to send one header like:

  • –header ‘x-site-context: {“date”: “{{timestamp}}”, “channel”: {{channel}}, “account”:"{{accountId}}", “stage”:"{{stage}}"}’

  • The above header will have corresponding values

When i setup the data source with this header, the API gives internal server error
But when i call this rest by Postman, it works fine

All other normal headers work just fine.

#2

Hi @Ankit_Gaur, welcome to the community. We will check this and get back to you

#3

Could you share the section of the API definition that shows the headers injected. I have attached mine below for example

...
"headers": {
    "x-site-context": "{\"date\": \"{{timestamp}}\", \"channel\": {{channel}}, \"account\":\"{{accountId}}\", \"stage\":\"{{stage}}\"}",
}
...

Also, could you share the version you are using?

#4

I am using cloud v: (v3.2.2)
API def section:

              "headers": {
                "x-api-key": "sample",
                "x-site-context": "{\"date\": \"2022-03-09T16:29:54.538Z\", \"channel\": 12, \"account\":\"sample-acc\", \"stage\":\"sandbox\"}"
              },

Also in the postman it goes like:

--header 'x-site-context: {"date": "2022-03-09T16:29:54.538Z", "channel": 12, "account":"sample-acc", "stage":"sandbox"}' \

What might be happening is that this header should go as string, the upstream guys must be json decoding this. And tyk is changing it such that json decoding is failing on their end.

Thank you very much

#5

Hi, Is there a solution for this? I’m having the same errors.

#6

Headers naturally take string values, so encoding and passing it as base64 should resolve the issue. You would simply need to decode it when it get’s upstream.

#7

Is there another workaround other than asking the upstream to decode the header? We don’t own the upstream, so it will be hard for us to make any changes on the upstream side.

Will this be supported in the future?

#8

I tried using ASCII characters but no luck. I will ask internally if this is possible.

#9

FYI, the same header works if I wrap my service inside a rest tyk API, but it didn’t work if I apply it inside UDG api

#10

Yes, @Ankit_Gaur confirmed this. I have reported this internally and will update this thread when I get a response. In the meantime, a workaround is to convert it to base64 and avoid any quotes " or reverse solidus \ in the header. You could also try removing any reverse solidus characters that get upstream at the backend. However, this requires you own the upstream or can modify it in some way or form.