Many use cases for Airtable’s Scripting Block (and also for Custom Blocks) involve making requests to services running on another domain. Since scripts execute in the context of a web browser, such requests are restricted according to the Cross-Origin Resource Sharing (CORS) protocol. Users’ requests are frequently blocked for this reason. At the moment, the Scripting Block does not offer a solution for this problem nor does its documentation recognize the need. Some Airtable users have found a publicly-available service to meet their immediate needs, e.g. CORS policy error when trying to fetch API - No 'Access-Control-Allow-Origin' header API calls to a NodeJS/Express application with no domain name This is undesirable for a number of reasons: users must discover the service on their own (This obstacle is particularly daunting for the entry-level programmers for whom the Scripting Block is designed. Even experienced developers can struggle with the complexity of CORS.) the reliability of the service is not guaranteed the trustworthiness of the service is unknown (The proxy has access to all the information intended for the destination service which frequently includes sensitive data like API keys and database contents.) If Airtable provided a CORS proxy, it would fill what some might argue is a hole in the capabilities of the Scripting Block. It could confidently educate users on how/why to use the service, guiding them away from unsafe practices and toward more resilient solutions.
... View more
