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?
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 ?
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.
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…)
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!
