Process for Removing Unused Images Uploaded via Widget
I am curious to see if there is an established best practice for removing images no longer used from Cloudinary if they've been uploaded with the Widget and the only reference available is the image display URL provided by the widget.
Our System
Front end:
- Client can upload an image using the Cloudinary javascript widget
- Client can:
- leave page without saving it to his account (orphaned image in cloudinary)
- replace an existing image (previous image saved is no longer in use/orphaned)
- save image to his profile. In this case, we save the image's display URL in the backend
Back end:
- If user has saved the image, the image's display URL overwrites whatever is in the field representing that image in the database. There are multiple tables with multiple fields that store these URLS, so no one singular "images" resource to retrieve from.
If this scenario is common and has a well established process to remove the orphaned images or images no longer in use, please let me know.
Otherwise, our thoughts are:
- Let user upload image through widget
- On successful upload, send a message to our servers that an image with given URL has been uploaded to cloudinary (as well as in which table/field/resource it is being stored for)
- Enqueue this message into a background job queue with url, resource identifier
- Wait some amount of time (a week or so)
- check our database at the identified resource location (table/field) to see if the upload URL matches what is in the queue.
- If so, leave it alone; if not, send a delete request to cloudinary
- remove our queue message
-
Hi Chad,
I think using the `return_delete_token` can support your use-case. The token enables you to delete the uploaded image within 10 minutes of the upload. So, if your user doesn't want the image, you can simply delete it.
Please note that it is recommended to save the image's `public_id` and not the whole URL (to allow future manipulations and versioning).
Your alternative workflow can also be supported. You can implement it using the widget's API methods .
0 -
Hi there,
I am also considering using the JS/jQuery client to allow (maybe unsigned) uploads directly from our webpages, but I would want to protect against wild, rampant uploading and/or automatically have unsigned images that weren't "confirmed" be automatically deleted within a certain period of time.
I'm wondering if it would make more sense to flip this idea around and have a `return_acknowledge_token`, which must be used within 10 minutes to keep an upload around on Cloudinary. A system whereby a token is passed from Cloudinary after a successful upload must used to "confirm" or "acknowledge" an upload seems more assuring to me than one where my backend may have no idea that a file was uploaded at all. There may have been an error on my site after the upload to Cloudinary, but before my backend became aware of any ID or tokens, or some bad actor could be abusing my account, so I'd possibly end up with lots of "orphaned" files in Cloudinary.
Any recipe you can think of that works in this manner? I was considering what the OP suggested, Notification URLs, or perhaps using some system involving Manual Moderation...but they're all less ideal than having Cloudinary require a signed acknowledgement from my backend that I'm aware of a file that was uploaded and I'd like to keep it there.
Thanks for all the great work on Cloudinary!
0 -
Hi Chris,
Thanks for sharing your feedback.
We currently don't support a feature like 'return_acknowledge_token', or equivalent. As you mentioned, you can use both upload notifications and/or a moderation mechanism.
For Fetched resources, you can set an expiry policy and automatically delete the resources once in a given interval.
That being said, I'm forwarding your inquiry to our product team to review, so we might be supporting such behaviour in the future.
0
Post is closed for comments.
Comments
3 comments