How to generate Url using public id for android and iOS SDK ?
-
Hi Viral,
Thank you for reaching out. All our SDKs include URL and image tag helper methods which will automatically generate the image source URL and HTML image tag respectively.
Click here to read more about it and see Android and iOS examples. You can apply the same technique if using videos which you can read more about here.
Please let me know if you need anything else.
Thanks,
Thomas0 -
Hello Thomas,
Thank you for the quick answer..
however, still I am not able to generate signed URL.
The image edit tool display this URL -> And from android the URL is generated this -> https://res.cloudinary.com/rheo-tv/image/upload/s--cQaaMa5P--/v1/Test-Viva/d4hqfbdmtl6qynz8ajzs.jpg
which does not return anything.
the code for generating URL from SDK is this -> After getting the signature from the backendval url = MediaManager.get().url().signed(true).generate("Test-Viva/d4hqfbdmtl6qynz8ajzs.jpg");
0 -
Hi Viral,
No problem at all and thank you for getting back to me.
I'm unsure of what your backend setup is but I would recommend you send the fully signed URL straight to your frontend, instead of just sending the signature and using the mobile SDK to generate the URL.
Signing directly from the mobile SDK is not advised as you would need to expose your API secret in the frontend and anyone could see it. The earlier doc I sent is more for when you need to generate URLs for unauthenticated assets.
In your case, I suspect the API secret is not present for the SDK to use so the corresponding signed URL is still invalid as I don't see you utilising the signature which you sent from your backend based on your code snippet.
Click here to read more about signed delivery URLs and here to read more on how to generate them manually if required.
Thanks,
Thomas0 -
Hi Thomas,
Thanks for the answer.
As per the answer I can understand that we need to generate the signed url at the backend side.
However, its not possible for us to use backend for generate signed url for each resource, as we rely upon server less infrastructure like firebase, we cannot use backend.
Therefore we'll need to generate the signed URL in the frontend(mobile sdk) only. We need to make sure others can not access the media other than the mobile applications.
if its there a way to achieve this, let me know the way? Otherwise let me know the alternatives I can use0 -
Hi Thomas,
Can we use token based authentication from the mobile SDK side without requiring of backend for server less environment0 -
Hi Viral,
Thanks for getting back.
You could use token-based authentication but you would still be exposing your token generation key on the frontend which we highly advise against. Also, token-based authentication is a premium feature so you would need to be on an advanced plan or higher.
Are you able to tell me why you need to use signed URLs?
If you must use authenticated assets or control access then you will definitely need a backend to create the signature if you want to protect your API secret. You could also do a 'hybrid' model where you have a small server-side endpoint just for signing URLs created in the client-side apps but this still requires extra work and may not be feasible.
If you're fine with only specific derived copies of an asset being accessible then you can upload your assets as private and enable strict transformations. When you upload an asset as private, only derived assets are accessible without a signature so when used in tandem with strict transformations, only derived versions pre-generated at upload time using "eager transformations" will be accessible or transformations you specifically allow for dynamic use. Click here to read more about private assets and strict transformations.
Also, from your earlier messages, you mentioned that you were able to generate a signature from the backend so you could use this and construct the URL manually in the frontend. Click here to find out more about how to construct a signed URL.
Please let me know if you have any other questions.
Thanks,
Thomas0
Post is closed for comments.
Comments
6 comments