I am using a REST API Resource to interact with my interface-less API backend and use Retool to build an administration section.
Situation
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/1.1 302 Found
Server: Cowboy
Date: Mon, 22 Nov 2021 12:40:42 GMT
Referrer-Policy: strict-origin-when-cross-origin
Location: https://mybucket.s3.eu-west-1.amazonaws.com/myobject?aws_specific_auth_query_params ⬅️ *A temporary public URL*
Issues
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).
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 ?
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.
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 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
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.
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?
Hmm it does look like the same error that others have gotten when hitting this bug
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?
But thank you for checking in! I'll share this feedback internally
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