Update access mode method not available in SDK about cloudinary_php

[brandon14]

If there is another way to modify the access_mode (NOTE: Not the access_control parameter that is available via the update() method, then that would be acceptable. just wanted to make sure that the omission of this functionality, and divergence from the documentation, was intentional.

[aleksandar-cloudinary]

Hi @brandon14 - Thanks for getting in touch. That method is indeed not supported for the PHP SDK so it does appear that the Documentation is the part that should be updated - I'll speak with our team about that internally. We plan to sunset the Access Mode feature so it's not present in all SDKs and especially the new V2 SDKs.

In terms of potential workarounds, what you could try is to send a direct API call to Cloudinary (not using the SDK) passing the relevant parameters to update the access mode of that asset. For example, you can use cURL or any HTTP library and make a POST request to /resources/:resource_type/upload/update_access_mode and pass the required/optional parameters as per (https://cloudinary.com/documentation/admin_api#update_access_mode). The Admin API uses Basic Authentication as the authentication method so that can be passed quite easily to the HTTP client itself.

For example, via cURL (you'll need to substitute the placeholders in all caps):

curl -X POST https://API_KEY:[email protected]/v1_1/CLOUD_NAME/resources/image/upload/update_access_mode -H "Content-Type: application/json" --data '{"public_ids":["MY_PUBLIC_ID"],"access_mode":"public"}'

Would you be able to try this out and let me know if it works for you?

[brandon14]

The cURL request does work, and this could be a potentially viable solution. If plans are to sunset this functionality that is fine. The reason I ask is I was writing an updated Flysystem adapter for Cloudinary, and it optionally supports altering visibility, but most of the adapters I have seen for Cloudinary just omit the functionality. I was thinking if it was as easy an API call like that, then I would add support for that, but it's not a big deal. I mainly wanted to bring it up as well to make sure it wasn't something overlooked, or something wrong in the documentation.

[aleksandar-cloudinary]

Thanks, @brandon14 - I agree, since it's not supported it should be removed from the Documentation's code examples (I'll update that from our side) to avoid confusion as to whether the Docs is right or the code is missing the implementation.
If you just want an asset to be Restricted and in some cases Public, then you could use Access Control instead. On Free accounts, you won't have an Access Key to generate a valid token for accessing Access Control Restricted assets, but you can block access to the file by setting Access Control on the asset and then when you need to make it Public you can do that too.

[brandon14]

@aleksandar-cloudinary Thanks for the reply. This is good to close as long as the documentation and examples are cleaned up.

[aleksandar-cloudinary]

@brandon14 - You're welcome. - Absolutely - we'll update the docs to remove that to avoid such confusion going forward.

[lk77]

i have the exact same issue, passing access_mode to Cloudinary::admin()->updateUploadPreset() does not work

[aleksandar-cloudinary]

@lk77 Hi, Indeed, that option is not one of the supported Upload API parameters in the new SDKs hence it's not passed in the request from the SDK to Cloudinary. That said, you should see the Access Mode option in the UI (Settings > Upload tab > Upload Presets) and be able to set it there for the upload preset you want to update.

[lk77]

@aleksandar-cloudinary yes but it fallback to public every time i update the preset with the admin api,

it should :

• either set the access_mode
• or don't set the access_mode but don't override it and keep what the user put with the ui

Also a patch route would be useful, in the end i only want to update the notification_url

Having to retrieve the preset, modify the url and send it back to cloudinary adds an unnecessary step i think

[aleksandar-cloudinary]

@lk77 Yes, the API performs an update so unless you pull the details, modify the object and send it back in the update() call, it will overwrite with the relevant parameters in your last request. There are long-term plans in regards to deprecating access_mode in favour of access_control hence why the new version of the SDKs do not support access_mode, unlike version 1 of the SDKs. PHP is the first backend V2 SDK that has been released currently, while V1 SDKs like NodeJS still support that parameter.