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]

Maor_Conforti:

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.

Maor_Conforti:

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]

EvanHahn:

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,

EvanHahn:

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

[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]

Maor_Conforti:

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.

Maor_Conforti:

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.

Maor_Conforti:

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

[EvanHahn]

Bill.French:

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.

Maor_Conforti:

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.

Maor_Conforti:

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

EvanHahn:

you shouldn’t rely on the attachment URL being stable

Understood and thanks for the additional clarity.