Switching from AirTable to Baserow

Workspaces Software (General)
1

Yesterday I discovered a security issue in our use of the AirTable API: our JavaScript web apps that post to AirTable contain the API keys. Now AirTable has very limited permission options for their API keys – they are either “full access” or “read only” for the whole user account. In AirTable Pro and higher (20 EUR per user and month for one workspace), there is a feature “Field and table editing permissions” allowing to selectively grant edit, create and delete permissions to collaborator users (and thus their API keys) (source). But even that does not help, as such users still can read all the data in the workspace or base they got shared access to, and that may contain personal data entered by other users.

So if users would extract the API keys from the web app, until now they would have access to all our AirTable data. There is no indication that anyone ever did so. But of course I plugged this security hole by disabling the AirTable API key.

We don’t seem to have active campaigns or forms currently that rely on AirTable, so there is no immediate damage. However, the question is how to proceed from here.

Options include:

  • Secure AirTable API key access via Netlify lambda functions, as described here and here. This is quite elegant as it does not force us to run an own server application, and we use Netlify anyway.

  • Secure AirTable API key access via a proxy server. This would require us to run a small server application on our host, and some development effort. Relevant base repositories for this are daniloc/airtable-api-proxy and, derived from that and extended a lot, avanavana/airtable-api-proxy.

  • Switching from AirTable to Baserow. Baserow is an open source alternative to AirTable, and its API seems more mature. For example, they support database access tokens with separate per-database permissions for create, read, update and delete of records (see). That allows to keep this type of API key right inside our Javascript applications, as we can set the API key to “write only” access. So unlike with AirTable, there is no security issue with API keys in the application.

I discussed this with @owen and we decided to give Baserow a try. So I will install it on our server, and the next time Owen needs a web database, he’ll use that one. It’s an open source solution, so much more in line with our style than AirTable (which easily becomes annoying with its “upgrade account” messaging).

The only downside of this is that right now there is no straightforward way to collect Typeform responses in Baserow. @nadia wanted us to use that kind of connection for data collection for the remote work audits Edgeryders started to do. But in October 2021, Baserow folks intend to add Zapier integration, and with that it will be possible to make this connection.

This topic is for the progress reports and issues around our migration from AirTable to Baserow.

4 Likes
2

oki

3

lets not rush into something we then have to change in october so do what you feel works well and Ill adapt to that

1 Like
4

I had a little look at the Baserow API, and it has some advantages over the AirTable offering.

The most useful one is being able to get metadata for a field (the field type for example - which for some reason is completely absent from AirTable’s API). This could potentially enable forms to be generated directly from the table based on an ID of the table - skipping the JSON configuration entirely.

The only thing missing to make this work would be a way to add a text description to a field, so questions can be written for each column. AirTable frustratingly does have field description boxes for every column, but again they are not accessible through the API.

Just some food for thought, it could be an easy (and cheaper) alternative to developing some kind of form configurator.

1 Like
5

Hmm that’s an interesting idea for us to get rid of Typeform in the longer term: just create a Baserow table and give access to a certain user, it’s automatically available as a form somewhere.

For field descriptions, if nothing else works than this approach would do; it’s similar to how MySQL and PostgreSQL store metadata about their tables. You’d add another table field_descriptions with columns table_name, field_name and field_description.

1 Like
6

@matthias Do you have an eta for getting it up and running? Thanks!

7

The issue is that this overlaps with us wanting to install a whole new server due to the move to Ubuntu 20.04. Means, I have to install the server first and only then have the environment to set up Baserow.

I can get both done until end of the month. Hope that works? Could be done a bit sooner as well, if necessary.

8

No problem and no pressure, just to get an idea of the timeframe - thanks @matthias!

9

hey is this what you were talking about re setup for the cards? Remember to time report it to @ivan please

10

Cards do work without Baserow, as we still can use AirTable. Baserow would be better, and being paid for installing it is even better, but that work has to wait a bit longer still. Too much other stuff piling up.

1 Like
11

Have you considered just using a Cloudron instance? Takes most of the pain out of self-hosting. Installing Baserow would be the work of seconds. The server would have already updated itself to the latest Ubuntu version.