Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mixed Content warning when serving over HTTPS #70

Closed
skube opened this issue Sep 26, 2018 · 6 comments
Closed

Mixed Content warning when serving over HTTPS #70

skube opened this issue Sep 26, 2018 · 6 comments

Comments

@skube
Copy link

skube commented Sep 26, 2018

Just curious, I'm seeing a Mixed Content warning in Chrome Dev Tools Console:

Mixed Content: The page at 'https://www.mywebsite.com/' was loaded over HTTPS, 
but requested an insecure video 'http://res.cloudinary.com/mycloudname/video/upload/v1/mypublicId.webm'. 
This content should also be served over HTTPS.

How does one force https when using this component?

@eitanp461
Copy link
Contributor

@skube this weird, since the protocol for serving images from Cloudinary relies on the window.location.protocol, see https://github.com/cloudinary/cloudinary_js/blob/a50f25d3bb308c98549308667836fe165f9ff383/src/configuration.coffee#L15.

You can force the SDK to use HTTPS by providing the secure attribute, e.g.:

<CloudinaryContext cloudName="demo" secure>
     <Image publicId="nice_couple" width="300" crop="scale" />
</CloudinaryContext>

See full example here - https://codepen.io/eitanp461/pen/pOZwJe.
You can copy the HTML from the pen to a local server and see how the secure attribute affects the image delivery URL.

You can find a complete list of supported configuration parameters here - https://cloudinary.com/documentation/solution_overview#configuration_parameters

@skube
Copy link
Author

skube commented Oct 8, 2018

I added the secure prop and it works. Thanks!

<Video 
   secure
   ...

@skube skube closed this as completed Oct 8, 2018
@ronnyhaase
Copy link

Hello, we noticed the same issue just today with v1.1.0.

@strausr
Copy link
Contributor

strausr commented Mar 15, 2019

@ronnyhaase did you try the solution above?

@ronnyhaase
Copy link

Yes I did, @strausr and it works.
But I think it would be nice if that wouldn't be necessary and to have a look at the actual reason.

@pho3nixf1re
Copy link

The problem for us is that we do SSR which does not have access to window.location.protocol. So when it is rehydrated in the client not only is it mixed content but the app HTML does not match what React renders causing issues. The solution is manually setting the secure option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants