Help

Upcoming database upgrades. Airtable functionality will be reduced for ~15 minutes at 06:00 UTC on Feb. 4 / 10:00 pm PT on Feb. 3. Learn more here

What is the URL structure of attachments?

Topic Labels: API
5640 20
cancel
Showing results for 
Search instead for 
Did you mean: 

When getting a record with a pdf attachment through the Airtable API, I see that the URL of the pdf attachment has the following structure:

https://dl.airtable.com/.attachment/<long-hash-code>/<short-hash-code>/<filename.ext>

Attachments thumbnails have the following structure:
https://dl.airtable.com/.attachmentThumbnails/<long-hash-code>/<short-hash-code>

What is the long-hash-code and what is the short-hash-code?

Can I assume that both hash codes will change when the pdf if replaced?
Can I assume that both hash codes will not change unless the file was replaced?

20 Replies 20

Yes, I believe this is an accurate assumption. I have not tested this to be certain.

Yes. My experience building Airborne is that you can bank on these URLs as immutable.

Just in case this is what you’re doing, we don’t currently support using Airtable as a CDN. Relatedly, we are in the process of making changes to the way attachments are hosted/served, and can’t guarantee fully static URLs per attachment for all time.

Sorry if that throws a wrench in any of your plans, but hope this helps.

Understood (and anticipated).

Can any solution vendor guarantee this? It’s unreasonable to think this way as we build solutions around Airtable. We have to embrace the idea that nothing is set in concrete. However, can we assume that until such changes are made, the location of an attachment is immutable until something material changes such as:

  1. The file is removed?
  2. The file is replaced?
  3. Airtable’s attachment architecture changes?

Evan,

Nor should you.

Related to this topic are the attachment URLs themselves (which are publicly accessible).

I (and many of my clients) have trepidation about this and it is a factor that often rules out Airtable as a choice. Unbeknownst to most users – all attached documents in a base are openly exposed in a CDN-like environment (i.e., dl.airtable.com). I get it - the hash-keys for any given document are unpredictable and this is the basis for claiming they are secure.

“Security by obscurity” are often the last words any CEO remembers just before seeing the “On-Air” light flash from a chair at CNBC as they queue up Kate Fazzini to drill you about a security breach. :winking_face:

I have to believe you and the team are pondering how and when this design must change. Have you considered signed-URLs and a new API method that would give us the ability to create signed URLs for attachment documents?

@Bill.French, this is an important idea, that should be in its own Topic.
If it doesn’t already have its own topic on this forum, then I suggest that you post a new topic about it. In any case, it is not directly related to this discussion.

Thank you @EvanHahn.
I write a script that downloads attachments to my web app database on a daily basis.
I do not want to download again files that are not new and have not changed. So I’m looking for a short signature for each attached file and thumbnail that reliably represents each file, and would change if the file changes. Preferably the signature is not the full URL. The can be fine if I could rely on it. At least until you make any architecture changes…

@EvanHahn, can you please explain why are there two hash codes in the URL, and what each represents?

Perhaps you are right. I’ll be happy to delete it and make a new post as soon as you get an answer to your question. Until we know that answer, it’s difficult to say what may be relevant to understanding how to build services on top of Airtable that reliably access attachments.

I defer to @EvanHahn, but I believe each attachment id is unique and the data it ascribes to (which includes the URL of the associated attachment) is specific to that attached file. From my experience, no other attachment id will represent this data.

When a record with attachments is duplicated, the record ID is different (as expected). The ids of the attachments are all the same as are the URLs associated with those IDs.

This, of course, is different than saying if the URL of the attached document for any given immutable ID is also immutable itself. And I believe that while the URLs are [presently] immutable, they are not unique within the context of attachment IDs.

As mentioned earlier, you can duplicate any record and see that the attached document URLs remain constant for both records. This isn’t surprising.

I was also tempted to press Airtable for this information some time ago, but I realized just a discussion of how these numbers are cast is a potential security breach. If anyone could fabricate valid numbers like this, it would expose the content completely and create serious security risks. This is why I believe my earlier interest is relevant to your line of inquiry.

If the file store fell under the same security model as all other Airtable content, I would love to be able to predict attachment URLs - this would make it possible to know when content has changed or how to render access to a collection without enumerating every item.

However, given the openly accessible nature of files in the Airtable attachment file-store, they (nor we) want attachment URLs to be predictable or understood at any level. We also do not want even a small glimpse of how it could be deconstructed or what it represents. As such, I implore @EvanHahn to not answer this specific question. :winking_face:

I’m not on the team that works on attachments so I don’t have 100% clarity, but I believe this is on our radar and something we’re aware of (no promises or ETA for release). I agree that this should be a separate topic.

Would the attachment ID work for your purposes? That lets you treat the URL as an opaque URL.

As I mentioned above, I’m not on the team that works on our attachments architecture. My understanding is that, currently, they are just two random IDs. We could’ve had just one random ID, but we wanted to avoid a somewhat obscure security vulnerability involving browser Service Workers. Again, not totally sure about this, but I’m confident that you shouldn’t rely on the attachment URL being stable.

Understood and thanks for the additional clarity.

Hi
@Moe
@pory

Interesting Airtable DEV’s & Consultant’s topic I think, but I imagine you anticipated or fixed this potential built-on-top-of-Airtable’s FrontEnd no-way ?

Best,

olπ

Thanks for this question - it is something I am also working on.

Apologies if I missed this in the thread but is there a way programatically to get the <long-hash-code>/<short-hash-code> then? I understand they are random hashes - but what are the parts that make the hash?

I have a script which is currently looking to pull the images down locally - pdfs are fine, pngs are fine but for the pngs I have to know this <long-hash-code>/<short-hash-code> url to be able to query it.

Many thanks guys!

Answered my own question! The hashes are returned in the attachments object under thumbnails!

The time for using Airtable as a CDN for hosting files one the web has finally come to an end.

Just got an email. Never saw this topic before, so I was not aware of any upcoming changes.

Since I have (enterprise) level clients who have been using the functionality long before the 2019 warning (e.g. for reporting) this will be interesting…

Also, if this is only about security, a simple switch (field level) which defaults to the new concept would have provided backwards compatibility. They’ve done that before.

Evan, can images be a security risk, the type of security risk Airtable is mitigating by making this change? Is there any way Airtable can make an exception for image attachments? This change is going to destroy all of our workflows.

Hi @EvanHahn , I’d like to reopen this discussion. I use Airtable in a no-code environment (Thunkable) and I got this announcement yesterday (Oct 31 2022). So I have some days left before the new structure gets activated and I don’t know what will happen to my apps. For example I use an attachment field for icons that get displayed in a list of items to choose from. The app gets those icons during start and the icons don’t change very often. Refreshing this list every hour or so would introduce more network traffic.

I understand that Airtable does not sees their services as a CDN and that expiring links can be a way to improve security. But from my point of view the level of security should be chosen from the users side. When I store some static elements in an attachment filed (like icons) I would appreciate to decide by myself if those links may expire or not (like the suggestion from @Tuur ). So I suggest to have this “expiring flag” changeable on a field base. This option should be set to “will expire” as a default, but I would like to have the choice.

Best, Michael (PS: sorry if I have written in the wrong section, I don’t come here often as a no-coder…)

In our case it has nothing to do with a CDN either.

Hi @Michael_Rogulla ,

The change that Airtable is making (linked above) makes a lot of sense. There was never any “share attachment feature” in Airtable - public sharing of Airtable Data can be done by sharing “Views”. I don’t think the attachments were intended to be shared in a Google Docs way.

There is a lot of smart people on this forum and at some stage people realized that there actually is a public URL for attachments, that can be used for different shortcuts.

If you need to have a permanent link to an attachment you can use Make.com to create a webhook, that will request the attachment via Airtable API.

I made a video about it some time ago - you an also use it to control expiry date of your webhook link and turn sharing on/off:

If you are using this for Thunkable - going via Make.com can be an OK solution for prototyping and mild traffic. If you get serious traffic it will be cheaper to hire someone to set up CDN rather than pay for Make operation cost.

CDN for images is a very different scope from Airtable. To efficiently serve images on websites you not only need regionally distributed edge servers, but also image optimization that will dynamically show:

  • right optimized format for user’s browser - mostly .webp - which are about 30% smaller vs jpgs
  • selection of scaled down images - properly configured <img> tag should apart from src contain srcset with selection of images to match screen size and DPR of user’s device - this also resuls in drastically smaller files → faster page loading times.

CDN for images is complicated enough to make it a business on its own as in case of cloudinary.com, which can be a relatively easy no-code option to upload and host images.

Absolutely the best code option is using Next JS/Vercel and their image component :slightly_smiling_face: You just provide it with a URL of image (which could be NextJS API route, returning image from Airtable) and it renders automatically srcset with optimized images cached on Vercel network. Magic!