Securely Storing Third Party API credentials & Importing External Node JS Libraries

[Anthony_Gualand]

I’d like to get some clarification for how to import external node js libraries into custom blocks to work with other third party api’s within the blocks. I see statements on the Airtable help docs that say you can do this, but no documentation for how to do it properly and any limitations that exist.

Also, there is no info online anywhere about whether storing your api keys in a airtable custom block or script is secure or how to do it securely. I’d like some guidance or documentation on this if possible.

[somehats]

hi @Anthony_Gualandri! Thanks for the questions.

Anthony_Gualandri:

I’d like to get some clarification for how to import external node js libraries into custom blocks to work with other third party api’s within the blocks.

Apps (formerly blocks) run in the browser, not on Node. This means that you can’t use libraries designed specifically for node, but a lot of packages on npm are supported in the browser too. To use them, you can run npm install <package name>, then in your code do import package from "package name";. For example, if I wanted to use the groupBy function from lodash, i’d run npm install lodash in my terminal, then add import {groupBy} from 'lodash'; to the top of the file I wanted to use it in. Once it’s imported, I can use groupBy anywhere in the file I added the import to.

Anthony_Gualandri:

Also, there is no info online anywhere about whether storing your api keys in a airtable custom block or script is secure or how to do it securely. I’d like some guidance or documentation on this if possible.

We don’t have a good story here at the moment. We’re very much aware that this is a problem though, and have been thinking about how we can better solve this issue.

Right now, my suggestion would be to refer to what Airtable’s own apps do for storing API keys - typically, that means storing it in globalConfig , including it in a password field in a form. There’s a a big issue with that though - that API key will be accessible to anyone who has read/write access to the base. Because of that, you should include a strong disclaimer in your block UI explaining those issues to the user to help them make an informed decision.

[Anthony_Gualand]

somehats:

including it in a password field in a form

Thanks for the reply @somehats! Glad to hear you all are conscious of the problem and are working on a more direct solution. Can you clarify what you mean by the above quote about password fields? Also, wrt scripting apps vs custom ones, how do you store things like api keys in globalconfig? I see how this is done in custom app, but not totally sure if it’s possible in a script app.

[somehats]

For the password field, I mean providing a settings page in your app where you/your users can supply an API key. You could use an <InputSynced type="password" /> to automatically save the value to globalConfig.

The scripting app doesn’t have direct access to globalConfig. Instead, you could either:

1. hardcode your API key in a script
2. join the script settings beta and store the value there
3. prompt the user to enter the API key each time the script is run

Note that with the first two options, again the API key would be visible to anyone who has access to the base and you should warn about that in the UI.