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]

kuovonne:

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?

If I said …

… will not be deeply affected by this change

That would be direct knowledge of their architecture and plans. I used “should” because I’m uncertain and this seems like a reasonable expectation. Airtable has a duty to try to sustain backward compatibility.

kuovonne:

The custom apps sdk currently only provides the same attachment url available in scripting

Indeed, but it runs in the client, so there’s an expectation that whatever URLs are available to the client, they should always work. Ergo, it’s probably a safe bet that signed URLs will work just dandy in custom apps.

[Jordan_Scott1]

@ScottWorld working with the team on pulling this together!

[Ambroise_Dhenai]

I’d like to try to clarify a few things, as I see there is even more confusion here that I thought there would be.

For comprehension’s sake, I’ll consider a delay of 2h before the initial public link is changed/invalidated (I have no idea what will be the exact delay)

Airtable

What will not be affected:

• Attachment fields within Airtable (seeing a CSV file, picture and modify them, within Airtable)
  • If all users use Airtable directly, they won’t be affected while using the Airtable UI

What will completely break:

• Any usage based on a formula (e.g: pictureUrl) that gets the public URL of an attachment. This will work for 2h and then the public link will display a 404.
  • :warning: This is a very common use case and will be one of the most painful breaking changes (IMHO)
  • If you embed an Attachment (picture, pdf, csv) in an email, this will continue to work, because the attachment itself will have been copied and embedded
  • If you share the public link of an Attachment (picture, pdf, csv), this will only work for 2h, as the public link will then be invalid and return a 404
  • The formula pictureUrl will not be updated, it will become invalid/stale after 2h
• Other examples
  • Sending a Slack message with a public link toward an attachment will only be valid for 2h
  • Using Integromat (Make)/Zapier for sending public URL toward an attachment will only be valid for 2h

Third parties

Now let’s look how will this affect third-parties tools such as Stacker, Noloco and Softr.

Those tools usually have a “cache” between Airtable and their customer-facing UI, we’ll consider they do. (Stacker and Noloco do for sure, I don’t know about Softr)

What will not be affected, or slightly affected:

• Attachment fields (seeing a CSV file, picture and modify them, within the chosen tool)
  • Those tools fetch the Airtable records and will always get a valid public URL, because even if Airtable changes the public url every 2h, since those tools keep fetching the most recent data, they’ll keep receiving a valid public url
  • Unfortunately, those “refreshes” have delay. For Stacker, it can be up to 15mn. If the public URL changes every 2h, and Stacker updates its cache every 15mn, there will most likely be a “up to 15mn” window of time where the public link used by Stacker will have changed on Airtable but not reflected in their cache. Thus, displaying a broken image on Stacker UI. (same for Noloco and Softr, although their exact refresh delay might differ and cause more/less issues)

    • :information_source: UPDATE: Noloco is not simply using a cache as I thought, but they actually store the attachments on their own server for a while, so they are not subject to the above issue as they’ll always display a working attachment, no matter how frequently Airtable invalidates public urls. Stacker also stated that change will not break their app.

What will completely break:

• Displaying the public link of an attachment (coming from a Formula field) will only work for 2h
  • :warning: This is a very common use case and will be one of the most painful breaking changes (IMHO)

Airtable REST API

• The API will not behave differently from the UI. If you fetch an Attachment field, the attached public URL will always be valid, until “Gods know when”, as we probably won’t know when the next public link auto-update will happen, which will invalidate the associated public link and will require a new fetch using the API to get the new correct value.
  • Using a Formula field like pictureUrl will only work for the first 2h, after what the link will be stale

So, what will really matter here is to use the public URL from the Attachment field, not from a Formula.

:warning: Static websites might break. This will break static websites that rely on the Attachments public urls, because they use those urls directly and usually don’t update them once the site has been published.

For example, websites built using Next.js (SSG without timeout) and similar technologies will cease to work properly at most 2h after the build, as all links to Attachments fields will have changed, if they don’t host their own version of the attachments.

Airtable automations

The automations themselves won’t break, but what they do might, depending on what’s being done.

• When using Attachment fields, it should just keep working.
  • Sending a picture or document in an email (embedded), etc.
• But, if you use an Airtable formula, the link will only be valid for the first 2h
  • Displaying a direct link to a picture or document

---

Potential solutions

The most viable solution is either not use Airtable attachments directly, or to mirror any Attachment to another system that will not invalidate the links.

• https://on2air.com/content/on2air-help-center/more-details/customer-feedback/new-app-ideas-1/new-app... Mentioned above, haven’t tried it and I don’t know how it’s meant to be used. If it’s an App it’s might become an issue due to the 10 Apps limit per base :person_shrugging:
• If you’re using a 3rd party (Noloco, Stacker, Softr) that stores your data into Airtable, you might ask them to mirror the attachment to another provider while uploading it (store it elsewhere, and maybe store it into Airtable for backward compatibilty, too). In this case, you’d use the Airtable Attachment field as before, and the mirrored public link (stored outside of airtable) for all automation/integration related stuff.

Practical solution example

I’m in the same situation as most of you, I built a business that displays a logos and pdfs on static sites, to help students find financing solutions. All those links will break with this update, all logos and PDF links will cease to work. Also, we have Editors (customers) who use a Stacker app to manage/edit those records.

What I know I must do is:

• Keep the Attachment fields as they used to be, to allow Editors to see/update them in their Stacker app (I don’t want to break their workflow)
• Add a mirrored public url to those Attachments, stored in another provider (I might use the BuiltOnAir solution, or build my own App to deal with that, I don’t know yet how we’ll achieve that, exactly)
  • Use those links on our static websites, so that I can keep using Static websites
  • Auto-update those mirrored links when the Attachment itself is updated

With this, I’ll be able to keep my Editor workflow similar (although the displayed attachment will most likely fail every 2h due to the caching delay of Stacker), and keep our website built the same way.

My ideal solution would be to not use Airtable Attachments fields anymore, but only store the public url link in Airtable, but this will require important changes on Stacker/Noloco to handle that properly so that the Editors workflow is not badly affected by this change.

---

I hope it helps understand the whole issue, how you’ll be affected, and how you can remediate it.
If you want my help as a consultant, you can get in touch with me.

[Ambroise_Dhenai]

I’ll update my previous post to take Noloco’s answer into consideration.

Thanks for sharing this, and for writing it. It’s great to let Airtable hear how people are actually going to be affected by this change.
Just to shine some more light on it from our side.
When you sync your base with Noloco, we actually don’t cache your data and files, we store it in our own database.
What that practically means is, when we get your Airtable attachment link (which will be valid when it comes from the API) we copy that file over to Noloco, so even if that link becomes invalid it doesn’t matter, because we have the original file.
The only change that might affect us, is how they display those attachments.
Currently (as you know) when you visit an attachment URL it display the file directly. I believe they’re going to be displaying the attachments in the UI (like a sharing link) after the change. We’ll have to figure out how to grab the file from there, but it shouldn’t be difficult.
I hope that clears things up a bit
Darragh - Noloco

[kuovonne]

Ambroise_Dhenain:

I’d like to try to clarify a few things , as I see there is even more confusion here that I thought there would be.

Can you please cite where Airtable states that urls from formula fields will work for two hours and then fail? I find the wording “become invalid” (versus “expire”) to be ambiguous.

[Ambroise_Dhenai]

• 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.
  Source

Airtable also use “invalid” term, by it I mean “expires”.

[kuovonne]

Ambroise_Dhenain:

Airtable also use “invalid” term, by it I mean “expires”.

And I think this verbiage is ambiguous. Why switch terms from “expire” to “invalid” unless something different is happening. I also did not see the term “invalid” used for other methods of obtaining urls.

Another interpretation of the wording is that formula fields with attachments will continue to use the same format (comma separated list of file names followed by the url in parentheses) so that people can continue to extract file names with formulas. However the actual urls will retain their September values in November, but cease to work at all.

There are also several technical issues if urls for formula field will work for a few hours and then expire.

While I appreciate your efforts to clarify the changes, I still feel that this extra clarity needs to come from Airtable directly.

[ScottWorld]

Exactly, everybody is just making educated guesses at this point. Nobody really knows anything until Airtable clarifies everything for us, which Jordan said that they are going to do soon.

[Bill_French]

Ambroise_Dhenain:

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.

LOL This is really starting to get fun. Okay - so - whoever crafted this text made a big mistake and that mistake is a conflation of negatives and positives. The only rational interpretation is:

1. Formula fields are always recalculating; this we know.
2. Any formula based on attributes of an attachment field will currently update just fine if they change; this we also know.
3. For any sort of rational compatibility going forward, formula fields must continue to reflect the ground truth of the attachment field attributes; recalculation is likely the pathway to achieve this.
4. Attachment field names and URLs already change (from time-to-time) and formula fields based on them update just fine when they do; this we know beyond a shadow of a doubt.
5. Attachment URLs that are influenced by the new rules for invalidation are likely to simply recalculate no differently than they do today.

If we’re confident that #1 through #4 represents true interpretations of the current system, #5 is the most probable outcome. Despite what the documentation says, the writer probably intended to say exactly what #3 through #5 say in far fewer words. :winking_face:

Ambroise_Dhenain:

Using a Formula field like pictureUrl will only work for the first 2h, after what the link will be stale

I predict (and will bet a fine turkey sandwich) that this will be proven wrong. The entire premise of a formula field is based on its internal awareness to recalculate when references to other fields change. The links will never be stale. In fact, I also predict and will happily place side bets for mac-n-cheese that no links inside the Airtable UI will ever be stale unless they were placed there by scripts that unsuspectingly froze them in time as static values.

[Bill_French]

kuovonne:

However the actual urls will retain their September values in November, but cease to work at all. There are also several technical issues if urls for formula field will work for a few hours and then expire.

I also agree that the wording concerning formula fields and attachment URLs is extremely ambiguous and conflicting. And as you make clear - both of these scenarios are breaking changes that the universe of users could never tolerate, so I think it’s fiction. We’re all in a froth for absolutely no reason whatsoever. Major issues with this CDN-related change abound, but this is not one that even rises to the top 20 issues.