What is the URL structure of attachments?

[Maor_Conforti]

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?

[Bill.French]

Can I assume that both hash codes will change when the pdf if replaced?

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

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

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

[EvanHahn]

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.

[Bill.French]

and can’t guarantee fully static URLs per attachment for all time.

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?

[Bill.French]

Evan,

can’t guarantee fully static URLs

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.

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?

[Maor_Conforti]

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

[Maor_Conforti]

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?

[Bill.French]

this is an important idea, that should be in its own Topic.

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’m looking for a short signature for each attached file and thumbnail that reliably represents each file

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.

why are there two hash codes in the URL, and what each represents?

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.

[EvanHahn]

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.

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.

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…

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

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

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.

[Bill.French]

you shouldn’t rely on the attachment URL being stable

Understood and thanks for the additional clarity.

[Olpy_Acaflo]

@EvanHahn

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.

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π

[Tony_Duchars1]

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!

[Tony_Duchars1]

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

[kuovonne]

@EvanHahn

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.

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

Changes to Airtable attachments

[Tuur]

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…

[Tuur]

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.

[Portfolio_Pet]

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.