Cloudinary secure option not working?

[jstockwin]

I'm running a site for a charity, the page here displays mixed content warnings, even though I do keystone.set('cloudinary secure', true); here, and use the handlebars CloudinaryUrl helper here as set out in the keystone docs.

Apologies for linking directly to a site, but it seemed the quickest way of demonstrating the issue. I've restarted the app many times, so that's not the problem. Am I missing something here..?

Also, sometimes these pages load without any content for me, but I've been unable to get anyone else to reproduce it... If the page loads without any content for you, I'd be interested to know so I can look into it further. It's probably just some newbie mistake in the route...

[mxstbr]

The page is loading perfectly fine without any mixed content warnings for me, so I'll close this issue for now as this is probably related to your local browser setup and not Keystone!

[jstockwin]

@mxstbr Okay, fair enough. I've tried multiple browsers though. You have to open the console to see the mixed content warnings. For me, the html code clearly shows src="http://res.cloudinary.com... rather than https...

[mxstbr]

Ah, the pictures didn't load which is why I didn't get any errors. My bad, I do see them!

Can you try adding secure=true here and then comment if that works? https://github.com/Students4Students/KeystoneJS-Website/blob/master/templates/views/committee.hbs#L13

[mxstbr]

If that works, can you try changing Line 181 of views/helpers/index.js to

return cloudinary.url(imageName, options);

and seeing what happens then?

[jstockwin]

Adding secure=true works.

Your line 181 seemed to be line 205 for me, which read return cloudinary.url(imageName, options.hash);. This has had very adverse affects.

[jstockwin]

Going to revert that last commit as it's a live site. Removing the .hash appears to have made it ignore all the options, including the width and height.

[mxstbr]

Ah, sorry about that—I'm not too familiar with that part of Keystone I'm afraid. Lets leave it at adding secure=true then, and I've opened keystonejs/generator-keystone#176 since I think this is a bug in the cloudinaryUrl helper method!

[wosevision]

Hey @mxstbr, I seem to be having this same issue in 4.0.0-beta.5 – specifically, the thumbnail images that get rendered into list view columns for Cloudinary image previews don't honor the keystone.set('cloudinary secure', true); option, which I only noticed after putting a CS policy in place.

Despite having *.cloudinary.com allowed through, the images are being blocked because they're being served from http instead of https.

If I had to guess, I'd say the issue might be buried in the column rendering for that field – do you think I'm on the right track? I feel like this.props.image.url.replace(...) should be conditionally using this.props.image.secure_url, but I don't know if that's just my naivety WRT the codebase.

[yao23]

It should be the issue in keystone/fields/types/cloudinaryimage/CloudinaryImageType.js, as the doc in http://cloudinary.com/documentation/image_transformations, cloudinary.url("sample.jpg", {width: 300, height: 100, crop: "scale", secure: true}) should work if passed cloudinary secure setting is correct. My keystone lib version 0.3.16.