Help

Airtable dropping support for public attachments :bomb:

Topic Labels: Collaboration
12069 58
cancel
Showing results for 
Search instead for 
Did you mean: 
Ambroise_Dhenai
8 - Airtable Astronomer
8 - Airtable Astronomer

: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.

image

58 Replies 58

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.

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.

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.

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.

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

image

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

@ScottWorld working with the team on pulling this together!

Ambroise_Dhenai
8 - Airtable Astronomer
8 - Airtable Astronomer

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.

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

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.

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

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.

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.

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:

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.

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.