In the app, I let users uplaoding an image, using a picture uploader.
When the user uploads a new one, I update the image’user for the new one but before that, I delete the file (previous image) using the “delete file” action.
The file is deleted on the amazon’s side but when I uses the second url (cloudfront, found using the “inspect” of any browser before deletion of the image), the image is still visible on the other url.
Example, the first url of the image, the one that is deleted is this one:
but the image is still visible on this one:
Is there a way to totally delete the uploaded images ?
I’m wondering, if I select (in the uploader) “make this file private”, does it prevent the file be hosted on the second url ?
It seems that like that (when attached to a user), the url is :
The image is probably just cached in your browser.
If u wanna confirm deletion dump your cache before checking or use another browser / session / device.
Thank you but even using different browsers, devices… the image is still visible…
(the image was uploaded yesterday)
Well then it’s cached in cloudfront I suppose.
The image has been uploaded and deleted 3 days ago but still visible using the cloudfront url… not sure about the cache…
Not a “big” issue but if a user want to delete an image, I just want to make sure the image is really deleted…
Actually, when you delete something in Bubble it just deletes that thing in Bubble, not in external repo/servers.
Even if you delete a file/image from your DB, you will be accessing to the file/image if you have the CloudFront URL. That’s because bubble doesn’t delete the file in the S3 server.
I think they should add an option to delete the object in the S3 server when deleting the file from DB.
It has nothing to do with deleting cache.
Thank you for your answer.
Do you know if there a difference if I select “make this file private” ? Is the file still hosted externally?
Yeah that would sound like a bug, wouldn’t it? (Because not expected behavior. Additionally, once you lose the pointer to the s3 URL you don’t have any way to know where that file still exists… do you?)
If you lose the URL it’s like you lose something in the ocean, you know that exists but you don’t know where
Yeah, this seems bad given that the thing stored (in s3) might represent private data…
Yes exaclty… It’s actually maybe in the terms and conditions of Bubble but if not, it might be added or expressed yes… and actually even on any websites created with Bubble if a picture uploader is added…
knowing that, just in case, I’m not gonna let user upload private pictures for their profile, I’m just gonna let them choose between a few images, like avatars … anyway, in my case, the profile pic was not really a big deal, not really necessary… it was just to know how it works…
I was curious about this too as I had deleted a file uploaded and it was still visible on Cloudfront. Initially I thought it could be cached on the browser, but all cleared and still present. I bookmarked a couple of URL’s that I had requested the deletion of the images on. I kind of gave up checking, but after a week they were still visible.
I checked today, roughly 5-6 weeks after I’m guessing and oddly one appears deleted and the other still visible.
Still alive: https://d1muf25xaso8hp.cloudfront.net/https%3A%2F%2Fs3.amazonaws.com%2Fappforest_uf%2Ff1529406053613x151469400618225340%2Ftest-property-04.jpg
I was thinking that perhaps upon request of deleting the image, it triggers Cloudfront to add this image to a scheduled clear up, that maybe runs every x times. But seeing as one image is still live and the other is deleted, I’m really not sure.
It would be nice if upon the deletion of the image, it can be removed from all external sources within a 24 hour time frame or week at the very least.
I realize this thread is more than a year old, but to answer your question… Yes, there IS a difference. Private image files are NOT processed with Imgix and are thus not hosted/served from the cloudfront domain. A private image file is served directly from Amazon S3, so if it’s deleted from S3, it’s gone and inaccessible.