Getting CORS error—what are the correct CORS settings?

App Building
1

I am getting CORS errors using this method because the javascript is run from a sandbox so the origin in fetch calls is always null. I've tried allowing every origin for PUT requests on my bucket, but it seems that AWS might have changed the handling so that null origin is always a CORS failure. I'm wondering if anyone has found a workaround? Here's my current CORS configuration:

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE",
            "HEAD"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    },
    {
        "AllowedHeaders": [],
        "AllowedMethods": [
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]
1 Like
2

Hey @Brandon_Pancost!

According to our S3 docs, your CORS config should be something like this:

[
  {
    "AllowedOrigins": ["https://example.com"],
    "AllowedMethods": ["PUT", "POST", "DELETE"],
    "AllowedHeaders": ["*"]
  },
  {
    "AllowedOrigins": ["*"],
    "AllowedMethods": ["GET"]
  }
]

If you don't mind sharing, what are you currently trying to accomplish? :slight_smile:

1 Like
3

I am running into the same issue. I have the recommended CORS config setup. However @victoria the problem I'm seeing is that Retool sets a request header Origin: null instead of Origin: https://[my-app].retool.com, so CORS fails no matter what the S3 config is. Why isn't the current origin passed through fetch requests?

This specifically happens with a JS query and explicit fetch(PRE_SIGNED_S3_URL) upload. My team is using that approach, instead of the Retool S3 Resource, because Retool requires an access key + secret key, which AWS now recommends against for security reasons.

@Brandon_Pancost did you ever find a solution here?

4

Hello @rt_alden!

Unfortunately Victoria is no longer on the team :smiling_face_with_tear:

From my understanding fetch() methods will not work from Retool unfortunately. Our backend infrastructure is set up for use of Resources and Queries to access APIs.

Could you link me to the docs where AWS says that using an access key + secret key is not recommended for security reasons? I believe we have a large number of users accessing AWS via the Retool S3 Resource without any issues, as that is best practice and should not generate a CORS error.

For you question on my the current origin isn't being passed through to fetch requests, I believe this is because the code executor/sandbox does not have privy to the current app's URL for security reasons and because the code is not set up to handle fetch requests as they might hang or have other issues.

5

Hello, I'm having a similar issue @Jack_T -

Our team is using fetch() methods in Run JS to make multiple GET requests to S3, iterating over an array for S3 file keys i.e. baseUrl/{s3FileKeys} while iterating over [key1, key2, key3, ... , key1000].

We couldn't find a way to effectively replicate this behavior using S3 Willing To Invest, for example, since it seems like Download a File from S3 only accepts one file key per query at the moment. We thought we can't manually create hundreds of S3 resources, so we resorted back to the fetch() methods.

A major problem with using fetch() methods for such multiple API requests is that the request origin is set to null, resulting in CORS errors for most of the servers, including the ones that we don't have control over their CORS configuration.

Would using Retool Workflows enable us to make multiple API requests with non-null origins? Or what are other suggestions from the team?

6

Hi @mighty-leo

Sorry to hear you are also having this issue, CORS is no fun :smiling_face_with_tear:

To answer your question, Retool Workflows are great for making multiple API requests using a loop block.

But for setting the origin to be non-null, this is something that can't be done from the Retool Cloud unfortunately.

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).

Let me know if either of those options work for you! :slightly_smiling_face:

7

Also, I found this thread in the forums about batching large numbers of requests and setting up a REST API using additional scope to give the request an origin to avoid CORS errors.

You can definitely set up either a JS Query loop block in an app or in a workflow.

Let me know if this works for your use case!