[Plugin: WordPress HTTPS (SSL)] Broken images when page non-secure

The code changes external resources to HTTPS if fetching that resource does not produce a 404. Can you provide an actual example?

Here is the link (after being changed to https):

https://ws.assoc-amazon.com/widgets/q?_encoding=UTF8&Format=_SL110_&ASIN=1592406521&MarketPlace=US&ID=AsinImage&WS=1&tag=gift0b4d-20&ServiceVersion=20070822

Remove the S on the HTTPS to see that it redirects to an image. Firefox doesn’t seem to attempt to connect at all as it sees an insecure security certificate and blocks it, so I suppose it might not be throwing a 404 specifically.

The plugin does not verify that the SSL certificate is valid, only that the resource exists. This issue is not very common and I don’t have a good solution in place, yet. Eventually I’m going to add in the concept of SSL Domain Mapping so that you could configure the plugin to take any occurrence of ‘https://ecx.images-amazon.com/’ on HTTPS pages to ‘https://images-na.ssl-images-amazon.com/’ automatically. You could configure this for any number of external domains.

I was just about to post a new topic when I read your last comment, Mvied. I’m working on making our whole site SSL only including the wordpress blog. We have a load balancer doing SSL offloading and I can configure a site global redirect to take care of all of the content on our site. But we have a wordpress plugin (digg-digg) that has hard coded non-ssl requests for which I can’t simply substitute “https” for “http” (because their use of akamai creates a server identification mismatch). A couple of examples are:

https://static.ak.fbcdn.net/rsrc.php/v1/yN/r/Rp8qyLZw2E2.png

which I need to replace with

https://s-static.ak.fbcdn.net/rsrc.php/v1/yN/r/Rp8qyLZw2E2.png

and

https://w.sharethis.com/button/buttons.js?ver=3.3.1

which I need to replace with

https://ws.sharethis.com/button/buttons.js?ver=3.3.1

(note the hostname changes from w.* to ws.*).

All of this is to say that the SSL Domain mapping feature you describe above would completely solve the problem for me. My current alternative is to work with the digg-digg developers to get a SSL patch, but even that is problematic for me b/c the normal way for digg-digg to determine if they should use the SSL URLs is to test $_SERVER[‘HTTPS’]. But in my case that test will fail (b/c we’re doing SSL offloading and by the time the request gets to our production server, it’s not SSL anymore). Your solution would be ideal for me, so please consider this a big upvote for the direction you described. In the meantime, I’ll probably modify our copy of the digg-digg plugin and offer it to the digg-digg folks as a patch.

Thanks!

You could patch their plugin to use my SSL detection. Gravity Forms has done this.

if ( isset($wordpress_https) && method_exists($wordpress_https, 'is_ssl')  ) {
	$is_ssl = $wordpress_https->is_ssl();
} else {
	$is_ssl = is_ssl();
}

I like this idea. I’ll still have to modify their code to build in the SSL Domain mappings, but this will at least allow me to globally request SSL and not have to worry that SSL offloading hides that fact that the user is requesting the page via SSL.

Thanks for this. And please post back if/when you decide to implement the SSL Domain mapping feature.

Thanks!