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.
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.
I cannot imagine Airtable announcing worse news. All of our content workflows will break. There is absolutely no way Airtable talked to their users about how this will impact them.
I’ve been searching all morning for an alternative and the best I’ve found is exporting our Airtable database to Xano (a no-code database) and rebuilding our automations there. I’m guessing that will set me back at least two weeks or more to complete.
I really hope there is enough user outrage that Airtable scaps this plan. And I totally agree that “security” is the thin veil reason. Incredibly angry right now.
Next to revealing the ability to edit records without logging in, and then pulling it a few hours later, this is Airtable’s dumbest move ever! We noticed the security issues of open URLs and exported CSVs just after we started using Airtable 3 years ago. But, as you say, there are other ways to deal with this particular security issue. Its going to break so much of our stuff.
We are a small club and we are not high-end users but we have tons of documents loaded in as attachments. I don’t understand the distinction between URLS that will continue to work just fine and others that will expire. I also do not know how to identify the ones that will break. This is a really confusing change and I hope that AirTable will change their mind on this.
If you used to copy the direct link of an attachment to share it with other people or services, this will not work anymore. The only thing that will keep working as usual are attachments you see within Airtable.
But the direct links to those attachments will expire and cease to work after a while.
I hope it’s a bit clearer.
Ambroise: thank you for the clarification. I am concerned about a sentence in the change description at https://support.airtable.com/hc/en-us/articles/4852449595671. The sentence is “If you are sharing a file with a colleague who is not collaborating with you in Airtable , then you will need to consider alternative ways of sharing the file attachment in question.” Several AirTable views are shared with some of our club members who are not collaborators. Some of these views include attachments (PDF files, Word files or pictures). Will our club members be able to view these attachments?
If you’re concerned about the recent change in Attachment URLs that Airtable just announced, we want to hear from you.
At On2Air, we’re exploring ways to overcome this. (We build apps for Airtable - on2air.com)
Let us know if interested and your use-case by filling out this form.
@Mark_Comish I don’t fully understand how this change will impact everything, but my current understanding as of right now is that both of the scenarios that you outlined above will both break.
p.s. I’d also like to point out that many people in these forums believe that I am an Airtable employee. I am simply an independent Airtable consultant and an Airtable user. I don’t know any more or any less about Airtable’s announcements than anybody else in these forums. :grinning_face_with_big_eyes:
Correct. It’s my understanding the link reference will work if the recipient acts on it relatively soon after the email is delivered.
But this is not unlike any field values plucked from your database and shared through email. A message containing a customer balance, for example, has a shelf life - it will expire and potentially much sooner than attachment URLs will be sustained. Attachments can now join what has always been the case where assuming a static snapshot represents an historical perspective that may have changed since it was captured.
I think this is not entirely the case. Imagine Zapier is used to snapshot an attachment URL and sent it via email somewhere. Or, it sends it to a Google sheet. With the November changes, about 30 minutes later that URL will predictably fail.
While we may be quick to blame Airtable for this behavioural change, this problem has always existed. Images can be removed and replaced after a static URL has been shared. The links (unwisely still work) but in this case, they point to an old image - not the current one which may have changed in the past few minutes.
Bottom line - data shared by value - is a bad idea. It’s ostensibly the act of making a copy and as we all know, copies are ideal for historical perspectives, not real-time perspectives. If you want to create systems that always represent ground truth - i.e., the state of the Airtable data - you must share by reference and that reference would be a view or other such interface that Airtable possesses and is able to render without the interference of a historical timestamp.
This page currently says “a few hours”.
So if you saw 30 minutes, there is confusion somewhere.
Any attachment URLs obtained via the public API and the CSV export functionality will expire after a few hours.
It also says
The links obtained by referring to an attachment field in Formulas will not change (for backward compatibility considerations), and will therefore become invalid.
Does this mean that the urls from formula fields will stop working completely on Nov 8th or does it mean that they will continue to work for a few hours and you will get a new value every few hours (or some other interval)?
I am a starting to think the former. But the wording isn’t as clear as I would like.
I think that this support page used to refer to the url of an attachment, but I’m not sure. It sounds like people using this formula will still see a url, yet the support page currently has no mention of that url becoming invalid or expiring.
There are numerous community posts and third party tools about extracting URLs from attachments, and the silence from Airtable about these posts could be taken for approval.
I wrote an app for extracting these urls using a formula field that had to go through QA with Airtable, and I was never told that using these urls was discouraged. Unlike the community posts and third party tools, my app underwent a line by line code review by Airtable, so the lack of comment by Airtable against using urls in this way was even more evidence that Airtable was okay with using these urls. Airtable knew that my app extracted urls from attachments, knew exactly how those urls were produced, and published the app. This was less than a year ago. Why didn’t Airtable say anything before the app was published? If Airtable had said they didn’t want that formula in my app, I would have removed it. (Given that it takes months for a custom app to go through QA, I suppose that I should remove it now and hope that it makes it through QA by November.)
I also could not see any documentation on how long urls obtained by a script or custom app will last. What if a custom app wants to display an attachment? It needs to get the url of the attachment. How long will that url last? Could these urls last for the duration of the session if the session is longer than a few hours? If they expire while the custom app is still trying to use that url, how will the custom app be notified that it needs a new url?
What if someone uses the dev console to see urls? How long will those urls last? (Although I don’t recommend using urls obtained in this way, I do wonder, especially for urls consumed by Page Designer.)
@Jordan_Scott1 There seem to be a large number of unanswered questions about this upcoming change — would it be possible to get more clarification from Airtable on these changes?
I can only speak for myself, but I am somewhat confused by the announcement, because I’m unsure of what will break and what will not break.
Agree - it’s highly likely the former.
Ha ha! You are dreaming. You really think the left hand knows what the right hand is doing in cases involving deep technical coordination. Vastly bigger organizations with lots of depth and experience in coordination get this wrong. Airtable has as a well.
Events and/or pubsub architecture. The days of REST APIs are nearing their end of usefulness. Business requirements have raced ahead while vendors continue to promote legacy interfaces.