I received a excellent reply from Cloudinary support. It’s taking me a bit of time to decipher
Thanks for contacting us, and for letting me know what you’ve tried and where you’ve looked for an answer already (that’s unusual, and appreciated!)
At a high level, there are two things it’s important to be aware of regarding how Strict Transformations works, which are that 1) Strict transformations affects what methods can create a new derived image in your account without some additional authentication being provided, and
2) Strict transformations doesn’t directly affect how an existing derived image can be accessed, nor how the original file can be accessed
A related concept to mention again is ‘derived asset’ - a common use-case for Cloudinary is that you upload original assets to us, then on your website or application you use a URL that tell us to return that asset, with some transformations applied in the URL, and the version with the transformations applied is called a ‘derived’ asset.
If I understand you correctly, you’d like to create a watermarked copy of an image, allow users to see that watermarked copy, but it shouldn’t be possible for them to see the original asset without authentication, or to change the watermark / add other options. Additionally, you’d prefer to hide what the transformation options used were.
In that case, here’s what I recommend
• Upload the original assets with type ‘private’, so that the original can’t be accessed without a signature, but existing derived assets can be accessed publicly: Media Access Control and Authentication | Cloudinary
• Enable Strict Transformations on your account: Media Access Control and Authentication | Cloudinary
• Create a named transformation in your account which applies the watermark, and also resizes the image to the size you need it for your application (I also recommend adding ‘q_auto: good’ as the quality setting to reduce file size further): Chained and Named Image Transformations | Cloudinary
• In your upload call, or upload preset, request that the watermarked copy is created via an eager transformation
• Alternatively, use the explicit() API method to create a derived version using that named transformation, if the files have already been uploaded
• Alternatively, if all the images will have the same watermark, ‘allow’ the named transformation in your account settings, which will allow new derived images to be created “on the fly” if they use those transformation options
• Use the URL of the watermarked copy in your application or website
With that strategy, users will see the name of the named transformation in the URL, but not the options inside that named transformation, and they won’t be able to access the original file by removing the transformations, or change the transformation options to remove the watermark
May I ask you to please take a look and see if that helps?
Developer Support Engineer
Customer Success team
I have updated the generator to include a private overload. What Stephen suggested works for me (as in theory). Save as private and share a signed link including a named transformation. This way I can share the image, scaled and watermarked, and the end user cannot access the original image.
I’ll set up a Cloudinary Generator app soon. So you can 1. generated a curl example and 2. inspect the blocks.
I’ll set up the generator app when the current project is ready for live testing. Here are some working blocks.
I would mate but what worked one day, didn’t the next. I decided to try a different way to get the Signature as this is the bit I had the most issues with just like some other. When I have a constant version, I will create a demo app. If only Thunkable had SHA1 encryption included.
I do know that I am using Cloudinary for a purpose it is not really designed for but these challenges drive me. Mostly mad but drive me
Think I finally have it @tatiang, @skulamester and others.
Using Convert Curl to HTTP Request yesterday I realised that the hashify was not returning the right hash from the url parameters using thunkables webapi url alone. Add the header and the text to as the body and fist pumps. Still testing but the first 10 or so have worked
Thank you for your research and sharing all the results with us, but I have a question. The eager does not work for me, I want a 200x200 image to be uploaded, but I hadn’t succeed. I hope you have some idea.
To date I take photos and through MEDIA_DB I upload to cloudinary. I needed to delete the photos on cloudinary. With a little research on the community I can now upload and delete if the image is on https: /// … but if it comes from a photo taken with a mobile phone or from an image gallery I have this error:
But if you’ve uploaded the image to Cloudinary, then you have a cloud-based url for that image. You wouldn’t be able to delete a photo stored on a phone using the Cloudinary API. The photo has to be stored in Cloudinary. You shouldn’t be using a file:/// url at all.
yes, but to speed things up, I would like to upload and delete with api_cloudinary. and the API upload files with https: // and not local files. I wanted to know if it was possible to remedy. Because alternatively I upload with cloudinary and delete with cloudinary api, of course.