REST API Redirected Query Forwarding Headers


I am using a REST API Resource to interact with my interface-less API backend and use Retool to build an administration section.


I want to let my Retool users download a file which is exposed behind a secured endpoint on my backend (through authorization header) which does a URL Redirection (HTTP 302) to a temporary public url.

HTTP Response of the REST API

curl -I -H 'Authorization: MyAuthorizationToken'

HTTP/1.1 302 Found
Server: Cowboy
Date: Mon, 22 Nov 2021 12:40:42 GMT
Referrer-Policy: strict-origin-when-cross-origin
Location: ⬅️ *A temporary public URL*


I encounter two problems here. The Query that I am building on Retool is automatically following the redirect and is leaking the authorization header by forwarding it to the redirect url.

Expected Behaviour

The headers are not forwarded
I can choose whether I want the query to follow the redirect or not and pick up the location myself in the metadata.

Help Needed

  • Am I missing something that might explain Retool's Query implementation choice of forwarding the headers ?
  • Am I missing a way to achieve my goal of requesting to my backend the generation of a temporary URL using the configured REST API Resource and access the response before the redirect ?

As a reference curl itself had this issue a few years back and fixed their implementation to clear the authorization header when the second host (the one redirected to) is different than the original host (the one requested that returned the HTTP 30X).


Hi @malkovro! Thanks for reaching out! Can we see a screenshot of the query where you have this implemented currently?

The Query is defined using a restapi resource, not many configuration options there to play with unfortunately:

We can see that Retool takes care of following the redirect and AWS is complaining about the authorization header that Retool bound to the request while it's not been instructed to...

Any ETA on when this security issue might be fixed ?

Hey @malkovro

We have a ticket on file for engineering to look into this bug. I don't have an ETA yet, but I'll reach out as soon as we're able to ship a fix!

I'd like to upvote this issue. I have a similar use case where my backend API is returning a 302 redirect with a location header of a pre-signed S3 URL of a large JSON data payload that is previously calculated/cached. The Retool query is following the redirect but since it is including the REST API's bearer token, S3 returns an error of:

Only one auth mechanism allowed; only the X-Amz-Algorithm query parameter, Signature query string parameter or the Authorization header should be specified


@Tess is there any chance that feature was considered for implementing? Another use case is when the first response returns an authorization cookie, but because retool by default follows the redirections this cookie is gone and not available by the time the whole request with redirects is complete. The switch to follow or not to follow the redirects would be sufficient enough. n8n has it implemented with a user selectable counter that let's the user choose how many redirects has to be followed. This feature would be very helpful also with the Custom Auth module in Retool.

Hi @suhl Not yet :disappointed: But thank you for checking in! I'll share this feedback internally

Our service has the same pattern currently (Authorization Header -> s3 signed url 302 redirect -> retool follows the redirect with the original Header -> error)

Are there any suggested solutions for this? It would be nice to not introduce special behavior just for retool to consume this data.

Hi @bvach-sofar I don't see any known workarounds on the Retool side :disappointed: You can't currently configure Retool to not automatically follow redirects or to remove authorization headers when redirected, but I'll add your +1 where we're tracking requests for this internally

1 Like

Thank you for the follow-up Tess.

Since we maintain the endpoint in question, we added an option for the server to respond with 200 and the signed url in the payload, rather than a 302. We then used the Retool Success handler to get the data in the signed url. In our case, it was images, and we could set the imageUrl on success. A bit kludgy, but sharing this idea in case others are in a similar situation.

1 Like

Thanks so much for sharing!

Good day Tess! I think I'm having this same problem, I just posted this in the forum [link], would you kindly confirm the root of my issue is the same as posted here by various fellows? And that no solution is available as of now. Or is it completely different and I'm doing something wrong?

Appreciate your time!

Hmm it does look like the same error that others have gotten when hitting this bug :thinking:

What is the auth method you're using in Retool? What do you mean by run the same API call but with a different query? Is one get all and the other get a specific report? Do you know if those endpoints behave differently?