Airtable dropping support for public attachments :bomb:

[Ambroise_Dhenai]

:bomb: Airtable is dropping public url support for attachment in an upcoming update that will take place in Nov 2022.

This basically mean all urls to all attachments uploaded prior to that date will cease to work, and all attachments public leads uploaded from there will only work for a “few hours” (would be great to know exactly how long, by the way).

Supposedly being a security update, it’s more of a shitty update, speaking frankly. There are many other ways to achieve a similar result (where security is enforced) while doing it in a smart way that doesn’t hit all customers where it hurts.

This will break like all our current workflows using attachments, and makes the nice UI to upload file completely obsolete to us and all our users.

For instance, allowing to specify in the Attachment field whether to use a temporary link (and how long) would be so much simpler and effective.

So, my take is that Airtable does this on purpose, because this way it forces all end-users to use Airtable the way they intended to, through the UI, with a dedicated account. :money_mouth_face:

But even those users will get hurt with this update.

Official email

On November 8, 2022, Airtable will improve the security of our attachment URLs by incorporating an expiring links functionality. Once this change takes place:

• Any attachment URLs obtained via the public API and the CSV export functionality will expire after a few hours.
• URLs obtained from copying an attachment cell value will open the file to the attachment viewer within the product, instead of directly opening the file.
• The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid; the filename obtained in the same way will continue to work as expected.

Who is impacted?

Users who are storing attachment URLs anywhere directly outside of the Airtable product for persisting an attachment.

What is the reason for this change?

This change will make attachment URLs more secure to use in the Airtable product.

What do I need to do?

If you have workflows with attachment URLs that will be impacted, you can begin migrating them over to comply with the new functionality now by following the steps in this help article.

Additionally, on November 8, 2022 when secure attachment URLs launches, you’ll also have the opportunity to opt out of the migration for a 3 month period of time until we fully switch over on February 7, 2023.

[Bill_French]

ScottWorld:

I’m unsure of what will break and what will not break.

It’s probably not possible for Airtable to know this with any degree of precision because there are so many ways – some good, some crappy – to build external apps.

Ideally, Airtable has perfect knowledge about every use case and wackadoodle approach we have implemented to use Airtable content. But this is simply not possible. What we can ask for is a clear representation of the architecture and from that, everyone can make good assessments and expectations of performance as they seek new ways to abuse Airtable as an accidental back-end.

[kuovonne]

Bill.French:

Ha ha! You are dreaming. You really think the left hand knows what the right hand is doing in cases involving deep technical coordination.

Actually I need to revise my statement. Airtable gave me a suggestion on how to revise the formula for extracting a url because the format of the url might change. So I did get feedback that the url format would change, but no indication that the url would potentially expire, would never be valid to begin with, or otherwise should not be used. So the left hand must have had some communication with the right hand. Just apparently not enough.

If urls from formula fields will produce never valid urls starting in November, this affects two of my apps that are already published, and another app currently in development. None of these apps need to use urls from formulas that have an extended shelf life, and only one sends that url outside the Airtable interface (where it is only used for a few seconds.)

You may very well say that I should re-write the app to get the url from the attachment itself instead of the formula. However, I want my users to be able to do things like provide a height and width to all the images in a single attachment field or wrap each url in different html tags based on the file type. I know how to do this with formula fields, but having to move this logic into my app in a way that is easy for my users is impossible.

[ScottWorld]

Bill.French:

It’s probably not possible for Airtable to know this with any degree of precision because there are so many ways – some good, some crappy – to build external apps.

Right, but I barely understand the very basics of what this change means. And we don’t even understand under what circumstances the URLs will expire, and when the URLs will expire. The very little information that has been provided so far doesn’t even allow me to tell my clients with confidence whether their solutions will break or not break.

[kuovonne]

Bill.French:

Events and/or pubsub architecture. The days of REST APIs are nearing their end of usefulness.

In this case I was referring to a custom app using the blocks SDK, so the REST API isn’t involved. I suppose I might need to use a React hook, but I think that the hook would need to be written by Airtable. They probably have already solved it because it affects their own apps (especially Page Designer), but have not shared that info, and have possibly forgotten to consider that this affects third party app developers.

[kuovonne]

Bill.French:

What we can ask for is a clear representation of the architecture and from that, everyone can make good assessments and expectations of performance …

This information is what we are asking for. And by “we” I mean the top members of this community forum.

Bill.French:

… they seek new ways to abuse Airtable as an accidental back-end.

In the case of my apps, I do not consider my use of the urls as abuse or as an accidental back-end (although other people could use the urls obtained with help from my app in abusive ways).

In fact, one of my apps in development needs to use urls from formula fields and it never sends those urls outside of the app itself.

[Bill_French]

kuovonne:

In the case of my apps, I do not consider my use of the urls as abuse or as an accidental back-end

Neither do I. Internal apps should not be deeply affected by this change and I’m sure Airtable is working to ensure backward compatibility. In fact, for internal apps, there shouldn’t actually be the need for a CDN reference or any expiration. The Airtable client or proxies into Airtable data that run in the UI have a direct pipeline to these assets. It’s when you start casting content into the wild - this is where it will have the greatest impact.

[Bill_French]

ScottWorld:

we don’t even understand under what circumstances the URLs will expire

They have telegraphed that any URL captured from an attachment field is good for about 2 hours. Based on that, all URLs are subject to this new limitation. This is how signed URLs work - they have an expiration date/time and this creates two key advantages - added security and disincentives to create alternative frontends that use Airtable as an accidental (or intentional) back-end server/webhost/free CDN.

I think this alone is enough data to demonstrate where the impact will be felt most.

[ScottWorld]

Bill.French:

They have telegraphed that any URL captured from an attachment field is good for about 2 hours. Based on that, all URLs are subject to this new limitation.

We actually have no idea what it means for a “URL to be captured form an attachment field”, which is why we would need more clarification from Airtable and @Jordan_Scott1 on this, and why there is a significant amount of confusion on this topic.

The support article specifically mentions the API, so maybe this only affects REST API calls. For example, if a user just opens the attachment’s URL in a web browser, perhaps that behavior will not be affected at all.

Also, many people are concerned about copying & pasting the URL of an attachment into an email, and are unsure if clicking on that link will continue to work in the email AFTER a few hours have passed. Since a URL inserted into an email doesn’t use the REST API, it’s likely to assume that this scenario will CONTINUE to work in the future.

But again, the support article is so vague that I don’t think anybody can claim that they have full confidence on all the scenarios which may or may not be impacted by this.

[Bill_French]

ScottWorld:

We actually have no idea what it means for a “URL to be captured form an attachment field”

Okay - basics -

1. API requests a record with an attachment.
2. Attachment has a URL.
3. API process captures that URL
4. API process embeds that URL into a web page or uses the URL to render said image.
5. Airtable changes the address of the URL 120 minutes later.
6. URL and rendered image that were “captured” and stored in the wild now fail.

ScottWorld:

The support article specifically mentions the API, so maybe this only affects REST API calls.

Possibly. Certainly, any attachment URLs are likely to fail after the signed URL expires. But there are other cases where this could create problems such as an email message that used a fully no-code method to capture and store-forward an attachment address would likely fail after a short period of time.

ScottWorld:

Since a URL inserted into an email doesn’t use the REST API, it’s likely to assume that this scenario will CONTINUE to work in the future.

I think you’re dreaming. How would Airtable force all emails sitting in inboxes to magically change to the latest signed URL for an attachment that was exposed yesterday (for example)? You can easily mimic this test -

1. Create an automated email.
2. Include two data values in the email; an attachment URL and a field value.
3. Send the email with these values.
4. Open the email, verify they work.
5. Delete the image in the attachment and replace it with a different image; replace the data value as well with a new value.
6. Open the email - see how it works now.

But let’s say that Airtable were able to find a way to proxy the expired URLs for the latest URLs to requests from a known source (such as an automation) - like a link that was embedded through an email process. Doing so, would simply re-open the ability for abuse.

[kuovonne]

Bill.French:

Internal apps should not be deeply affected by this change and I’m sure Airtable is working to ensure backward compatibility. In fact, for internal apps, there shouldn’t actually be the need for a CDN reference or any expiration.

When you say should not be deeply affected are you speaking with actual knowledge of how it will work or are you stating what you think are reasonable expectations?

It also isn’t clear if Airtable thinks of third party marketplace apps as “internal apps” or not. The custom apps sdk currently only provides the same attachment url available in scripting, a formula field, and the REST api.

What do you think the custom apps sdk should provide for accessing attachments come November?

What do you think would be a reasonable timeline for Airtable to publish details on how the custom apps sdk is affected so that third party developers with apps already in the marketplace can adjust the apps and get through QA in time for their apps to continue working come November?