Hello,
Not sure if this is possible. It has come up before (thread) but there was no answer.
cc @thorsten.langner @Nicolas1 @Faustin
I am trying to store many text files inside of a tulip table then have a custom widget which can parse the text from those files. So far I have been unable to access the text because of CORS errors. Even though the signed url being generated by the custom widget input is available on the public internet.
I have tried many different header configurations and I even tried putting the fetch inside of an async function. No luck. Maybe something with the way Tulip hosts files?
Hello Daniel, I don’t know if it can help But I found a way using connectors and node red to get the text content of a .txt file.
I send the url of the text file using Tulip connector function to node red. Then I generate a signed url. After a simple get request to this Url, the text is here.
Hey Dan – this isn’t currently possible natively with Custom Widgets. Similar to the Node Red comment above, you could set up something like CORs anywhere to get around the CORs issue (you could fetch from that directly in the custom widget). You could also upload files into your own S3 bucket that would allow this.
For more technical detail on why this happens – COR (cross-origin request) restrictions prevent a malicious site from making requests of other sites that the user is logged in to. For example, a malicious site can’t send a POST request to the bank you’re logged in to and transfer all of your money. A site has to explicitly list out the sites allowed to make CORs (or use a wildcard).
We’re render custom widgets in an inline iframe with the sandbox attribute. This is to make custom widgets more secure – they only have access to what you pass in as props, not the entire application & authentication.
When using an inline iframe, the origin on any requests is set to null. The S3 bucket (or Azure blob store) where our images & files are stored is set to a CORs policy that only allows requests from tulip.co, so it’s rejecting the null origin coming from the custom widget. In order to allow requests with a null origin on the bucket, we’d have to allow all websites to make a request, which we don’t want to allow from a security perspective. Others outside of Tulip have asked for a change in browser behavior here, but that’s not coming anytime soon. However, if you uploaded the files to your own S3 bucket, you could use a more lenient CORs rule that what we’ve selected.
