Using secure prop with a custom cname results in incorrect domain path

[alextiley]

I'm trying to configure cloudinary-react to output images accessible via a custom cname. The documentation specific to cloudinary-react is very sparse and seems to show the happy path (using cloudName).

With the props below, I've managed to get image URL's to output like this (almost correct).

http://media.mysite.co.uk/image/upload/myImage

<CloudinaryContext cname="media.mysite.com" cloudName="mysite" privateCdn>
  <CloudinaryImage publicId="myImage" />
</CloudinaryContext>

The cloudName prop seems redundant but my app dies if I omit it. This is almost there, the only thing I need to do is point my images at https. So I then tried the following:

<CloudinaryContext cname="media.mysite.com" cloudName="mysite" privateCdn secure>
  <CloudinaryImage publicId="myImage" />
</CloudinaryContext>

(I've added the secure prop to CloudinaryContext).

Expected output: https://media.mysite.co.uk/image/upload/myImage Actual output: https://mysite-res.cloudinary.com/image/upload/myImage

For some reason, when adding the secure prop, the cname prop is ignored and the cloudName prop is used instead to incorrectly construct the {cloudName}-res.cloudinary.com domain string.

Am I doing something dumb? 😺

[strausr]

It looks like what you're doing is correct- (change to )

That being said, the cname you're using is not associated with an account mysite. We can set up your own custom CNAME for HTTP and a private CNAME in the Cloudinary domain for HTTPS, e.g.,

http://images.mydomain.com/... https://mycloudname-res.cloudinary.com/...

Or, we can set up your private CNAME in the Cloudinary domain for both HTTP and HTTPS, e.g.,

http://mycloudname-res.cloudinary.com/... https://mycloudname-res.cloudinary.com/...

These two options are available for the Advanced plan or higher.

[alextiley]

Hi @strausr

mysite isn't actually the name of the cname, I'm working on a private repository on the advanced plan and didn't want to share my client's information publicly.

I've opted to use the SDK directly now instead which gives me better results with the same data. However, I still think there is a bug in the way that your React component handles these props so it might be worth you guys investigating further. Up to you whether you close this ticket or not...but it definitely feels broken to me.

Thanks for your help.

[strausr]

@alextiley Thanks for the update. For future investigation, please open a ticket at support@cloudinary.com with more information on your implementation.

[staradayev]

@alextiley I don't know if it's still actual, but I've faced the same issue. After I've spend some time for investigations without any effect. While my colleague has sent the request to support team. The support team has passed an example, where some interesting, but not mentioned in React or Javascript or jQuery property has been appeared.

You should use a secureDistribution property instead of cname with privateCdn and secure props, if you don't want to changes in you URL.

So, as the result, you should have something like this: `

`

Cheers!