CORS Issue when trying to call Workflow through retool on webpage?

Hi guys,

I created a retool to catch data from a database with a webhook, so that I can display the data on a web page.

The workflow works like this:

  1. Webhook trigger
  2. I run a SQL query to fetch data from the DB
  3. I return the response to the webhook

Everything works, but I am now calling this webhook on a web page, and I am running into a CORS issue, which tells me that the domain is not authorized.

How can I by pass this since Retool doesn't allow us to whitelist domains; I believe?

I have the same issue, did you find a solution?

Hey folks! This is actually an active bug on our end. The dev team is looking into, fixing these errors and I can report back here when something has been pushed!

Also facing this issue...

Same. Can't move forward.

1 Like

Got it, I've bumped the ticket but we don't have an eta for it at the moment. Sorry that you're blocked - thanks for reporting it so that we have a better sense of how many people it's impacting!

1 Like

+1

Hey folks! The dev team pushed a fix for this with the 3.7 release - can you let me know if you're still having issues on that version?

1 Like

Hey, I am running into a CORS issue that seems to be introduced about 7 hours ago. Previously working fine because our team has an internal proxy that we use to call a retool workflow from our webpage.

I am wondering, is this related to the deploy?

Sorry for the late reply here @Gagandeep_Gill, what exactly is there CORS error you're seeing? And would you mind expanding a bit more on how you're making the request for my understanding?

Hey, did the CORS issue ever get fixed? I tried running a server that a JavaScript Resource would trigger locally with a fetch function to retrieve the data on it's behalf, but it's still running into this issue.

I read somewhere that the {{proxy}} function might work?

Hey @fcicyber!

JavaScript in Retool is typically sandboxed which can cause CORS errors when making fetch requests since they'll come from a null origin. I'd typically recommend using a REST query and calling that from within your JavaScript (e.g. using a Workflows function). Is there a particular reason you need to use fetch specifically?

Hey thanks for replying, Kabirdas!

Yeah, the reason for the using the fetch function is that our one vendor requires a dynamic edit in the header for each client we have on that vendor. So given 5 clients on that vendor, there might be 5 different domain regions I would have to call but with the same credentials, and then put them all in the same table.

Fetch allowed us to configure the REST GET call per each client, since we could not inject a variable in the headers option like you can with the body parameters in Retool Resources.

Curious to know more about your setup @fcicyber, particularly how the headers need to be passed. You should be able to pass dynamic header values through your function's parameters with something like the following:

Does your use case differ from the example above in a certain way?

Hello, I'm encountering the same issue -

I'm making multiple API requests by combining fetch and for loop in Run JS, but have encountered CORS errors due to them coming from a null origin.

I've temporarily worked around this by setting Allowed Origins to *, but the problem is when I have to make API requests to where I have no control over CORS configuration.

Don't think I can use RESTQuery effectively here - if I have hundreds of API requests to make by iterating over the different elements (e.g. S3 file keys), it seems like I need to manually create hundreds of RESTQueries.

Any recommendations from the team?

Hello @mighty-leo!

We run this code in our sandbox and when it leaves it we set this to null for security reasons unfortunately :sweat:

The best option would be to follow Kabirdas' recommendation above of using a REST Query and calling that from within you Javascript (using a Workflows function)

The two work arounds I have seen are:

  1. Using a REST API Resource instead of fetch. This should send the request through Retool's backend server, giving the request an origin of our server's IP address.
  2. Using a proxy to redirect request traffic. Using something such as an AWS lambda from a server where you can define the CORS policy and then redirect the request to the final destination you want to send it would allow you to set the origin and specify the callback URL for the response to be returned to (can also reverse proxy back to Retool through this intermediate server as well).
1 Like

Hi @Jack_T , for the self hosted deployment, if I define the SANDBOX_DOMAIN, will the origin still be set to null?

I am wondering if it's possible to execute a browser-side query without the CORS error of a null origin.

Hello @pablo.estrada,

Great question, I am not sure if that would work but it certainly wouldn't hurt to try that.

From the docs it seems that the SANDBOX_DOMAIN var will allows for using another domain to make requests to the backend, solving the CORS issue, let me know if that works :crossed_fingers:

I am trying to execute a frontend JS query (without going through the Retool backend). They are failing because the JS queries are sandboxed, so they have a null origin. I am looking for a way to get around this.

From your description, it sounds like setting SANDBOX_DOMAIN would just send queries to the Retool backend but have no effect on the frontend queries right?

Yes all the JS code is created in a sandbox for security purposes and there is no way for JS in the browser to make calls to anything besides the Retool backend. As queries to resources much go through our Retool backend or for self hosted users their backend container.

This is a known issue that many other users have tried to solve, but it is a limitation on what can be done with Retool because of how the code is complied and executed in a sandbox environment where the origin cannot be set. Which is done for security purposes to prevent malicious JS actions from occurring.

I apologize for the inconvenience!