3.0.6 Mixed Content

I am seeing the same mixed content issue on multiple sites. I have set Cloudflare to Strict SSL am implementing slowly to verify that all mixed content issues are cleared before setting site to force SSL in all cases.

The https rewrite was working in the early 1.3.x version of the Cloudflare plugin, and also (I think) with version 3.0.5

When I upgraded on site #1, the mixed content problem was with home page images embedded via site customization.

On site #2, I am finding issues with wordpress media images embedded within the page.

I can manually fix errors as needed, but obviously the rewrite protocol is failing to recognize and convert all local URL’s as needed.

I am looking at page now that has 3 images, and the URL was written for one, but not the others. I have no clue why.

Hi Guys,

So in 1.x of the plugin we had “Protocol Rewrite” which took “https://” and “https://” and rewrote them to “//”. Automatic HTTPS rewrite works a little differently. It only rewrites “https://” links which Cloudflare knows can be loaded over “https://”. You will still get mixed content warnings on your sites if you have content which can’t be loaded over “https://”.

We dropped support for protocol rewrite because we want to promote encrypted connections.

Thanks,
John

But that doesn’t explain the problems I described, because the content is images uploaded to wordpress on the same site. (generally with a path that looks like this: https://…../wp-content/uploads/….)

Obviously those images can definitely be loaded over https given that they are on the same site, and I can solve the mixed content issue by manually editing the image source on the pages and posts.

So the question remains: why is the https protocol rewriting selectively identifying some images and not others on the same site?

@abigailm, it’s because Cloudflare doesn’t KNOW that those images can be loaded over https. It doesn’t matter whether they CAN be loaded over https, it matters whether Cloudflare KNOWS it.

The way they KNOW (or don’t) is detailed in this blog post: https://blog.cloudflare.com/how-we-brought-https-everywhere-to-the-cloud-part-1/

Thanks for the response… but I have to admit that I don’t understand the blog post. And nothing in that comes close to explaining what my problem could be

I understand the concept –that the plugin is doing some sort of check to before rewriting a URL to make sure that secure content can actually be served.

But here is my problem and my question.

Let’s say I have the web site mydomain.com on cloudflare, and I have a cloudflare certificate set up properly, so https://mydomain.com is valid.

There is a page on my web site- let’s call it the “about us” page — and say that it has 2 images:

https://mydomain.com/image/first.png

and

https://mydomain.com/image/second.png

The problem I am seeing is that the cloudflare plugin will rewrite the https://mydomain.com/image/first.png to https://mydomain.com/image/first.png — but won’t do the same rewrite with https://mydomain.com/image/second.png — same domain, just a different image.

(and possibly a different path — because although I have simplified the example, in reality the image paths look something like this:

https://mydomain.com/wp/wp-content/uploads/2015/4/mypicture.png

Given that the plugin “knows” that https://mydomain.com is valid (obviously, given that it is the cloudflare domain) —

Why doesn’t it recognize ALL files on that domain as being loadable over https?

Your blog post seems to be mostly dealing with the problem of content from outside domains. I get that – but that’s not the problem I am seeing.

So please explain this to me:

Cloudflare has to “KNOW” that mydomain.com can be loaded over https –after all, cloudflare is setup as a DNS proxy for mydomain.com and Cloudflare is caching the images. And clearly it “KNOWS” that most of the images hosted at mydomain.com can be loaded over https — so why can’t it figure out that ALL of the images hosted at mydomain.com are equal?

Again — we are not talking about a random image pulled in from someotherdomain.com — we are talking about assets that are hosted on same domain.

First, it’s not my blog post – it’s Cloudflare’s and I don’t work for them.

Second, the new version of the CF plugin is not actually doing anything to rewrite URL’s anymore. That’s why I pointed to that blog post – the URL re-writing is happening at the actual Cloudflare layer of things (not within your WordPress site anymore). And to over-simplify things that are spelled out in more detail in that blog post, you could say that Cloudflare is only re-writing specific URLs that are on a giant list somewhere (that’s what they “KNOW”). And some of your URLs are on the list and some aren’t. The plugin doesn’t do anything to let them KNOW what to re-write and what not to re-write.

I’m not personally convinced that is the best way to do it for any given site, but I think for Cloudflare in general, trying to make something workable for every site in the interwebs, it’s probably the best they can do.

@pjv — I apologize — when I saw your post, I was under the mistaken impression that you were with Cloudflare, as I posted here in hopes that they would provide support.

While I understand your explanation, it does not resolve the problem that the current plugin simply doesn’t work for the intended purpose– so it is either a coding problem (bug) that the Cloudflare developers should know about, or else perhaps there is something that they can advise me to do to resolve the issue.

As it is, I cannot really deploy the upgraded plugin on most of the sites I manage until this is resolved. I am also not comfortable simply leaving the older plugin in place long term, given that it is no longer being actively supported, and therefore over time could end up with security vulnerabilities that would not be addressed.

Hi @abigailm,

Based on your description both of those files should be getting rewritten. Can you open a support ticket at https://cloudflare.com so we can debug further?

Please reference this page in your ticket.

Thanks,
John

Thanks, John.

I have hand-edited the files on the sites with the mixed content to correct the mixed content error, so I can’t submit a ticket on those. However, I have started with the smallest site, and if I find the problem recurring on another site. I currently have about ten wordpress-based sites on Cloudflare, and am trying to move gradually toward forcing https (as appropriate on a per-site basis)

But given the issues I observed, I am taking a gradual approach.

I downgraded to 1.3.24 and I quote exactly what Abigailm said before for my case as well:
“As it is, I cannot really deploy the upgraded plugin on most of the sites I manage until this is resolved. I am also not comfortable simply leaving the older plugin in place long term, given that it is no longer being actively supported, and therefore over time could end up with security vulnerabilities that would not be addressed.”

Is there an update coming that will resolve the mixed content for us not too tech-savvy and so work the same way version 1.3.24 does?

@catmaniax,

Unfortunately we won’t be supporting protocol rewrite in future versions.

Thanks,
John

John, I ran into a similar problem with a different site, involving a style sheet associated with a plugin. The stylesheet is local, with the path:

/wp-content/plugins/……/*.css

All other local stylesheets, including stylesheets associated with different plugins, are being properly converted from http: to https:// in the page headers.

I am leaving this in place for now so the problem can be seen for debugging. This issue doesn’t cause a mixed content warning – it just fails to load the stylesheet (noted in the console) and messes up the display of the widget. I assume that I can address the display problem by copying the needed styles into the main site stylesheet — but I am leaving it uncorrected for now so that the problem can be seen.

I did submit a ticket — reference #1269781

The widget display issue is visible on the home page if accessed via https:// (the difference can be seen on the sidebar, by comparing with the display on https:// — the styling provides a tabbed interface along with minor changes to typeface and spacing)

Hi @abigailm,

If you go to Settings > General and look at:

WordPress Address (URL)
Site Address (URL)

Are they hardcoded with https://? Does switching them to https:// fix it?

Thanks,
John

Same issue here… Since upgrading the plug-in when I look at my site modelers-reference.com through cloudflare the logo isn’t being rewritten.

Image of logo loading

Thanks for taking a look!
Mike

Hi @mchilson,

You’re getting mixed content error.

Mixed Content: The page at 'https://www.modelers-reference.com/' was loaded over HTTPS, but requested an insecure image 'https://www.modelers-reference.com/wp-content/uploads/2012/08/mr-logo-e1384879952954.png'. This content should also be served over HTTPS.

You need to load the image with https. You can do this by changing the url from

https://www.modelers-reference.com/wp-content/uploads/2012/08/mr-logo-e1384879952954.png to
https://www.modelers-reference.com/wp-content/uploads/2012/08/mr-logo-e1384879952954.png.

Thanks