Help

Re: Airtable domain used for fetch() requests?

1394 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Matthew_Thomas
7 - App Architect
7 - App Architect

There’s been a few recent posts about using fetch() in the new scripting block. Here’s another question/use case that’s not currently working for me.

My office uses Airtable for, among other things, tracking course videos through the editing process. Videos are hosted on Vimeo and one task we do is pull in the latest runtime. This can be done easiest through Vimeo’s oEmbed API which includes a “duration” field that provides the length of a video in seconds.

The problem: our videos are private and accessible through (able to be embedded on) a small whitelist of domains. Using the “old” API, this worked as I could set the referrer to our domain (the code was written in NodeJS and called the https.get() method). I’ve tried adding “airtable.com” and “api.airtable.com” to the video whitelist, but it still returns a 403 error.

Some initial searches indicate this might be a CORS issue with fetch() and it may not include the right options to make the request? Or it could be a bug in the scripting block/it is using a different URL than I whitelisted?

Anyone have any advice/tips/ideas?

5 Replies 5

Hmmm, the only think I can think of (perhaps you’ve already tried) is to set the referrer in the HTTP POST method (I assume you’re calling the API with POST) -

UPDATE - I just saw you are calling with GET, so this might work -

image

There’s all sorts of useful info here about cache-control and referrer-handling.

Matthew_Thomas
7 - App Architect
7 - App Architect

Playing around with the referrer (and ‘referer’, both spellings) and cache options from the link you provided both turned up unsuccessful.

I’ve paused on this approach for now and trying a new approach based on my existing server/code (but I’ll save that for a separate post).

Thanks for your suggestions though!

Matthew_Thomas
7 - App Architect
7 - App Architect

Just to post some code as a follow-up. I think this includes most/all of the relevant parameters listed in the fetch() documentation. I’ve also tried several different options for the parameters in different combinations, but no dice.

output.text('# Hello, world!');

let vimeoUrl = 'https://vimeo.com/api/oembed.json?url=https%3A//vimeo.com/';
let publicId = '392348731';
let privateId = 'xxxxxxxxx';

let runtime = await retrieveRuntime(privateId);

output.inspect(runtime);
output.text(`Video __${runtime.title}__ has a duration of ${runtime.duration} seconds.`);

async function retrieveRuntime(videoId) {
    let headers = {
        'Referer': 'http://airtable.com',
    };

    let response = await fetch(vimeoUrl + videoId, {
        method: 'get',
        headers: headers,
        mode: 'cors',
        cache: 'no-store',
        referrer: 'http://airtable.com',
        referrerPolicy: 'origin-when-cross-origin',
        //referrerPolicy: 'origin',
    })

    return response.json();
}

For reference, the following curl call is successful and returns a 200 “domain_status_code”, so the video does acknowledge Airtable as a valid referrer domain.

curl "https://vimeo.com/api/oembed.json?url=https%3A//vimeo.com/xxxxxxxxx" --referer "http://airtable.com/"

Calling Vimeo directly via the scripting block would be the ideal method, but given the current issues (and my progress with the proxy-server method) I’m focusing on the proxy-server approach for the moment. Just wanted to update this thread with the latest that I’ve tried.

Unfortunately, the subdomain for each block is unique. It follows the pattern https://*.airtableblocks.com, so you could try that if vimeo supports it, otherwise the proxy-server approach seems better.

Two Ideas

  1. Why not make the sub-domain name a block runs within be a function of the block ID?
  2. Why not expose the subdomain of each block as an attribute in script?

Either of these approaches would make the referrer predictable and unique and without risking any security.