hey all!
diagnosing this took longer than it should have, BUT...
when you use Retool Portals and point a DNS A record to your company domain, the HTTP requests for PUTting an object via Retool S3 resource do not jive with the Retool Docs as far as CORS settings for S3 buckets are concerned.
Docs say to set the CORS policy as such:
[
{
"AllowedOrigins": ["https://*.retool.com"],
"AllowedMethods": ["PUT", "POST", "DELETE"],
"AllowedHeaders": ["*"]
},
{
"AllowedOrigins": ["*"],
"AllowedMethods": ["GET"]
}
]
now someone who isn't just blindly copy-pasting will notice https://*.retool.com
does not match the custom domain they may have set as part of the Retool Portals features (eg. app.trapezoid.io
)
this will manifest as various odd behaviors:
- AWS policy simulator will say PUT requests should succeed for users/groups/roles assigned to the Retool S3 resource when IAM policy is copy-pasted from Docs
- Retool query will fail with no error message
- access from non-Retool clients will succeed (eg. a lambda function)
- only some operations fail (eg.
GET mybucket/myobject1
will succeed)
so yeah i thin the Docs should be updated to warn Retool Portals users who've enabled custom domain about setting the origin correctly, and the S3 resource should be updated to show it's a 403 access forbidden
response from AWS.