UploaderStrategy still requires api_secret if parameter was already added externally

[amirulzin]

This issue affects all current http artifacts:

cloudinary_java/cloudinary-http42/src/main/java/com/cloudinary/http42/UploaderStrategy.java

Lines 45 to 49 in 0907886

	if (requiresSigning(action, options)) {
	uploader.signRequestParams(params, options);
	} else {
	Util.clearEmpty(params);
	}

Compared to the implementation on cloudinary-android:

if (requiresSigning(action, options)) {
    String apiKey = ObjectUtils.asString(options.get("api_key"), this.cloudinary().config.apiKey);
    if (apiKey == null)
        throw new IllegalArgumentException("Must supply api_key");
    if (options.containsKey("signature") && options.containsKey("timestamp")) {
        params.put("timestamp", options.get("timestamp"));
        params.put("signature", options.get("signature"));
        params.put("api_key", apiKey);
    } else {
        String apiSecret = ObjectUtils.asString(options.get("api_secret"), this.cloudinary().config.apiSecret);
        if (apiSecret == null)
            throw new IllegalArgumentException("Must supply api_secret");
        params.put("timestamp", Long.valueOf(System.currentTimeMillis() / 1000L).toString());
        params.put("signature", this.cloudinary().apiSignRequest(params, apiSecret));
        params.put("api_key", apiKey);
    }
}

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 enter api_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.

[yakirp]

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

[OleksandrYuvkoExt]

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)?

[francistagbo]

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

[francistagbo]

Hi @OleksandrYuvkoExt

Yes, we do welcome users to create a PR.
We will review it once you have submitted it.

Thank you!

Regards,
Francis