Open amirulzin opened 6 years ago
Hi @amirulzin,
Thank you for pointing us to this issue, make a lot of sense.
Our Dev Team will review this for prioritization.
Thanks, Yakir
Hi, still no news? Java SDK don't allow to use pre-generated "signature", and trying to get "api_secret" even if "signature" is included. Is it allowed to create a pull request from side person(I will just move functionality from android repo cloudinary_android to cloudinary_java)?
Hi @OleksandrYuvkoExt,
Thanks for your comment! I am checking this with our team internally, I will update you once I have more insights.
Regards, Francis
Hi @OleksandrYuvkoExt
Yes, we do welcome users to create a PR. We will review it once you have submitted it.
Thank you!
Regards, Francis
This issue affects all current http artifacts: https://github.com/cloudinary/cloudinary_java/blob/090788607f1b92f895b7b79c67e1e628719666c6/cloudinary-http42/src/main/java/com/cloudinary/http42/UploaderStrategy.java#L45-L49
Compared to the implementation on cloudinary-android:
Cloudinary Android Source: https://github.com/cloudinary/cloudinary_android/blob/f7a0b32cfd9f2b6507bb6461043e6c89d9478c03/lib/src/main/java/com/cloudinary/android/UploaderStrategy.java#L43-L59
My suggestion is to implement that for each http artifact or simply refactor the android implementation upwards to the core
AbstractUploaderStrategy
.This allows
cloudinary-java
users to not have to enterapi_secret
if say the signature is generated via other microservices/authorization servers. This also allows easier server-side integration tests.While I understand the audience for
cloudinary-java
is more towards server users where the secret key is most likely exposed within a monolithic service, the two reasons above are currently forcing us to mangle a separate UploaderStrategy which simply use the above Android part instead.