Airtable dropping support for public attachments 💣

Like @kuovonne, I appreciate the depth of your comments, however, I think you used a very broad brush stroke that creates uncertainty that may also be misinterpreted.

Let’s start with the term “custom apps” which is known in Airtable circles to represent React apps that run as plugins to the Airtable framework. In my view, custom apps are the one place where exactly the opposite will occur - 100% of them will continue to function because they are indigenous to the Airtable UI and the Airtable UI does not have the luxury of utilizing invalid (or expired) URLs. This would be a vast breaking change and while I sometimes have trepidation about development choices at Airtable, I am willing to bet lots of fine sandwiches that the custom app realm is on safe ground.

Perhaps. But not in every case, and hardly “completely”. Imagine a Wordpress site that was built with data from Airtable as a “snapshot in time” - i.e., static web content. It has a cache for such things like images and other app assets and resources. Typically, just referencing an image will cause the web service to cache the image at the server much the way your browser does this for performance reasons. When a page loads, if the server is unable to resolve the link to the image or determine it has indeed changed with a conditional GET, it will render what it has in the cache. There are plugins and all sorts of features that developers can apply to sustain a business-as-usual outcome in the face of this Airtable policy change.

Because there are so many ways to implement server-side web caching – much of it already in place by default – you cannot assume every instance of static web content will fail. It may certainly be out of date - but we know that going in - it’s a static site. Suggesting that all sites built like this will be broken is an overreach and sensationalizing the issue.

In the past the formula result for an attachment only changed due to two factors: as part of the initial upload process, or when the filename was changed (either by the user or via code). While slightly confusing, the changing value due to the upload process was very brief and likely unnoticed by most users. The second change could be predicted by the user, and changed the filename only, not the url.

Currently the only formula fields that change values without a change to the underlying data is when a formula field used TODAY() or NOW(). While the frequency of updates to those formula functions have their own issues, at least their updating without a change to underlying data makes sense. Further, I cannot recall the exact sources, but I recall there was a test that showed that heavy use of calculated fields slows down REST API calls that create or update data, and heavy use TODAY() and NOW() also adds to the computation load of a base more so than other formula functions.

What you are suggesting is that formula fields based on attachments will now change even when the underlying data does not change. Also, there may be performance impacts due to these formula fields constantly recalculating.

Thank you.

I’m not one to speculate on the likelihood of a particular scenario. Mostly I was pointing out that it was a potential interpretation of ambiguous wording. I will try to wait patiently for official clarification.

I’m very tempted to take you up on that offer. I don’t think that the impact to custom apps will be large, but I believe that there will be an impact and potential code changes to custom apps to support this change.

Even with server-side caching (which I think you overestimate for static sites), the server-side cache will expire, thus breaking the static site.

1 Like

Actually, I am predicting they must now change, otherwise, they would have to consider no support for attachment field URLs in formula fields.

The exclusion involves cases where apps capture URLs and sustain them separately and apart from the database itself. If you are making copies of CDN values (a decidedly bad idea to begin with), there will be an impact on custom apps. But given the nature of a custom app and the tight coupling with the Airtable UI and the data, what requirement would cause such a need to preserve a potentially dated value for anything - even normal data fields?

You are right - when the cache expires, the server is obligated to reach out to the original location. However, when that fails, most web servers can be configured to gracefully lean on the cache and give it another timed cycle. Web servers are pretty smart little beasts and if you don’t take advantage of these concepts, you are creating a recipe for disappointed visitors. My point is that it’s impossible to say all static websites based on Airtable data will fail.

Yeah, you’re right, one cannot predict all custom apps will fail indeed. I only considered the small world of static sites where there is no dedicated hosting of attachment and thus relying on those Airtable public urls.

Also, the term “custom apps” was poorly chosen, I didn’t mean “Apps/Blocks”, but real apps that live completely outside of Airtable and are made of custom code, no matter what programming language is chosen.

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.

You seem fairly confident in this, I am not. It’s not technically impossible for them to make an exception to this particular case. Yes, it would be a behavior we’ve never seen from a formula, but considering how much additional computation would be required for formulas to stay up-to-date, this is a sound decision.

Edit : I’ve updated the post to lift some confusion, thanks for the feedback.

Hi all -

My name is Al and I’m on the ecosystem team here at Airtable. I wanted to jump in and say thank you for sharing your feedback with us on this topic. We’ve updated our FAQ documentation based on the conversation here to answer many of the common questions we’ve seen so far.

We also wanted to share some insights into how we’re thinking about this change. While Airtable is used for many things, it was not designed to be a cloud-storage solution that specializes in file hosting, permissions, and sharing (other tools such as Box, Dropbox, or Google Drive, may be able to better accommodate your hosting needs). In the last few months, we heard feedback from customers that there is a need to enforce more robust security standards to ensure that only authorized Airtable users can view attachments. Our team is continually focused on making sure that Airtable is as secure as possible, and we made this change because we believe it will provide additional security measures for your teams.

We understand there are some cases where this change can cause friction or disrupt your workflow. First, we apologize for the inconvenience. Second, we’ve summarized answers to some questions we’ve received below to help give you clarity on exactly what this change entails and are happy to answer any additional questions you have about this change. You can also find our support documentation with additional FAQ’s about this feature here.

How does this impact automations?

  • We will add the ability for users to select whether they want a viewer URL that points to an attachment for logged-in users to view, or if they want an expiring URL for downloads. Most automations will continue to work without modifications. Specifically, the send email action is not impacted by this change. Automations that use URLs in freeform text fields (like a send slack message automation) will default to using the viewer URL.

How is uploading an attachment via URL different than downloads?

  • This change applies only to attachment downloads, not uploads. You will still be able to upload attachments using URLs after this change is live.

Does this impact thumbnail URLs?

  • This change also applies to thumbnail URLs. Once created, they will expire after a period of time.

How is this different than shared views?

  • All shared views, including forms, will remain as is and aren’t impacted by this change. This change specifically concerns attachment URLs. These look like “https://dl.airtable.com/…” Shared views could be a great solution for workflows that rely on sharing attachment URLs today.

How does this impact APIs?

  • APIs will return expiring download URLs rather than permanent URLs, for attachments and attachment thumbnails.

If I copy & paste the URL of an attachment into an email, will clicking on that link continue to work in the email AFTER a few hours have passed?

  • Today, if you copy & paste an attachment cell from a grid view, you will receive a permanent attachment URL. Since these are going away, copy & paste is being updated to use attachment viewer URLs - these require that the person accessing the URL be logged in to Airtable and have permissions to view the base.

How does this impact custom apps? For example URL’s in formula fields

  • All Apps produced by Airtable will be compatible with this change. Most third party apps will also work without changes. We will provide guidance to developers of third party apps on how to ensure compatibility, however, we cannot guarantee that all custom apps will be updated before this change is live.

How many hours will the URLs remain active before expiring?

  • URLs will remain active for 2 hours before expiring.
1 Like

@Al_Biedrzycki Thank you for this clarification.

Is this summary correct?

Categories of urls:

  • non-expiring “viewer” urls that require a logged in collaborator
  • expiring urls that are good for a minimum of 2 hours and reach the raw file
  • invalid urls obtained from formula fields that will not work at all

Methods of getting urls:

  • Copying an attachment field (CMD+C, or CTRL+C) => viewer url

  • Native Airtable Automations => choice of “viewer” or expiring url

  • 3rd party integration tools such as Zapier or Make.com => choice of “viewer” or expiring url

  • CSV Export => expiring urls

  • REST API (which most portals use) => expiring urls, including thumbnail urls

  • Scripting getCellValue() => expiring urls, including thumbnail urls

  • Scripting getCellValueAsString() => invalid url to match formula value

  • Custom Apps SDK => same as scripting

  • urls from using “developer tools” of a web browser => expiring urls

  • Using an attachment field in a formula field => invalid url that never works

Questions:

  • If 3rd party integration tools will have a choice of urls, will those tools need reconfiguring to specify which url to use or will existing zaps/scenarios be automatically migrated?

  • Will scripting be given a choice of which type of url to use?

  • A bunch of other questions relating to custom apps that can wait to be answered in some other venue.

1 Like

Hi AI, thanks for sharing your feedback, I have a few questions.

How does this impact custom apps? For example URL’s in formula fields

You don’t actually mention how formulas will be affected. My understanding is that they will not update and thus will contain a valid link only for the 2 first hours, is that correct?

How does this impact APIs?

The Stacker team told me Airtable told them that the API will return Attachment links that will not expire before at least one hour. I believe there is some confusion about that, so I’d like to be crystal clear:
Will you disable the previous public url of an attachment at the same time that you’ll make a new one available? Or will there be several public urls alive at the same time for the same attachment?


For the record, I am one of the users who have requested some change about attachment security, that was 2 years ago. But I’m really not satisfied on how it’s implemented. It would have been much more effective to keep the current behavior while allowing us to specify which attachments should be protected, and how often to perform a public url change.

Not everything contains sensitive information, and it’s unfortunate that things like logo or cover images will become publicly unusable.

Might I suggest reviewing that choice and make this change happens at a slower pace?

For instance, by granting us the ability to choose which attachments to protect, instead of applying it to all, that would give enough time for the community to adapt and build new tools (like auto-synching attachments to a CDN, etc.) and only apply that change to all attachments 6-12 months after that first change? It would definitely give me more confidence in our ability to adapt to that change.

1 Like

Once again, I am highly disappointed with the “scorched earth” method that Airtable has taken in this situation.

1 Like

My disappointment is slightly different. I recognize that there are important security and engineering issues that we are not privy to.

I am disappointed that Airtable does not appear to have realized how much confusion this announcement would sow. What if, before the announcement, Airtable contacted well known consultants and 3rd party developers in advanced, placed them under NDA, and asked them what are the key concerns and confusions that people will have? Then Airtable could use that information to craft clearer messages. There would be less speculation on what would or would not break, and people could focus on adapting things that will break.

I thought that 2022 was the year that they promised better communication with us? :man_shrugging:t2:

Maybe they meant 2023. :stuck_out_tongue_winking_eye:

Years can get confusing — they all start with “20” these days. :wink:

Hi Kuovonne,

Your categories of URLs are correct. In regards to your methods of getting URLs:

  • 3rd party integration tools such as Zapier or Make.com will get an expiring URL (clarification is that there won’t be the choice of “viewer”)
  • Scripting getCellValueAsString() will result in an expiring URL

To answer your questions:

  • 3rd party integrations leveraging the API will have expiring URLs and will need to be migrated manually
  • For automation scripts, the existing URL will be an attachment viewer URL. We plan to add a new property to support expiring URLs.
  • We will be updating our support documentation soon with details about custom app implications with the attachment URL update
1 Like

Hi Ambroise,

Thanks for your follow-up questions and feedback. To answer your question:

Will you disable the previous public url of an attachment at the same time that you’ll make a new one available? Or will there be several public urls alive at the same time for the same attachment?

There will be several public URLs alive at the same time. We will guarantee that a URL will not expire within 2 hours of receiving it, so if a user wants to refresh their URLs every hour, they will always have a working URL.

In regards to your last point about the timing of the rollout, we plan to offer a temporary opt-out period so that you or your organization has additional time to plan for the change. Details on this opt-out process will be shared closer to the November rollout.

2 Likes

Thank you for this update!

I’m confused. Will scripting app and automation scripts get different results? Or will getCellValue and getCellValueAsString get different results?

For what it’s worth, I think getCellValue should get the expiring url of the raw under the url property for the best backward compatibly with existing scripts (both in scripting app and automation scripts). For example, I have written several scripts that parse the contents of a plain text attachment that that would break if the url were suddenly a viewer url instead of the raw file. The script would not break with an expiring url.

A new property of viewerUrl could be added, so that scripting could access both.

Since my categories of URLs are correct, I suggest a change to the wording on the support documentation. The support page currently says

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.

I suggest the following revision:

The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid on November 8, 2022. The filename obtained in the same way will continue to work as expected.

Or if you want completely different wording:

When an attachment field is used in a formula field, the result will continue to include both the filename and a url for backward compatibility considerations. Filenames extracted in this manner will continue to work as expected. However, the urls will be invalid starting November 8, 2022, and accessing these urls after that date will result in an error code.

1 Like

Anyone who has been using Airtable as a CDN for attachment images will need to move those images to a proper CDN service, and store the image url in Airtable instead. There are various techniques for moving those attachments to a CDN service. But how do you preview those images in Airtable when you now have only the url? You can click the url for the image, but that opens a new browser window that takes you out of Airtable. You could keep both the attachment and the url, but they might get out of sync and you really need to know the actual image on the CDN.

In this video I demo using my app Low Tech PDF with a premium license (a one time-flat fee per base) to preview an image url for the active record.

Here is the template that I used.

<h1>{{Name}}</h1>

<img src="{{Image URL}}" width="100%" />
2 Likes

Nice workaround.

Not so viable for big apps, especially for people constrained by the 10 apps limit (:roll_eyes:), but it might be a nice trick for a few people who need simple things like that. :+1:

If anyone has a new Pro workspace with the 10 app limit, I recommend reaching out to a consultant who can help them convert to a legacy pro workspace with unlimited apps.

Hello all.

Thank you for informing us at this time. We still have time. Therefore, we still have time to also make a change on the request, I believe.

Why don’t we give the user an option to make the column public or private based on a toggle on the creation of the field or editing the field? I believe that would make everyone happy.

With our implementation of https://nocodb.com/ , we enabled this feature, for example. We still use Airtable though. This will effect our public APIs, therefore we will have to find a solution to this. This will cause us to completely leave Airtable in the end, I believe.

@Al_Biedrzycki Would this possible to have this feature? Or, do we already have it? Thank you.

Thank you.

As I’m very new to Airtable, I’m not familiar with much of anything nuance wise here. So, was hoping someone with some more experience could translate: I am populating an Airtable table via my stores PoS API. The POS hosts the images for our products and I just pull the URL for the image in as a field to use on our website. Is this the kind of scenario that is impacted here? Perplexed newbie.

This topic was solved and automatically closed 15 days after the last reply. New replies are no longer allowed.