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]

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.

Ambroise_Dhenain:

This will break 100% of our custom apps

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.

Ambroise_Dhenain:

Static websites will all become completely broken

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.

[kuovonne]

Bill.French:

Attachment field names and URLs already change (from time-to-time)

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.

Bill.French:

I also agree that the wording concerning formula fields and attachment URLs is extremely ambiguous and conflicting.

Thank you.

Bill.French:

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.

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.

Bill.French:

I am willing to bet lots of fine sandwiches that the custom app realm is on safe ground.

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.

Bill.French:

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.

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

[Bill_French]

kuovonne:

What you are suggesting is that formula fields based on attachments will now change even when the underlying data does not change.

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

kuovonne:

I believe that there will be an impact and potential code changes to custom apps to support this change.

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?

kuovonne:

… the server-side cache will expire, thus breaking the static site.

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.

[Ambroise_Dhenai]

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.

[Al_Biedrzycki]

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.

[kuovonne]

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

[Ambroise_Dhenai]

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.

[ScottWorld]

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

[kuovonne]

ScottWorld:

Once again, I am highly disappointed with

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.

[ScottWorld]

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