Resolved: Zemanta Editorial Assistant issues with https/SSL

Resolved: Zemanta Editorial Assistant issues with https/SSL

One of the main reasons why I had left my admin panel open to server non-ssl requests was that Zemanta Editorial Assistant would not work properly behind HTTPS. I did some looking around and found that the same scripts were being sent over to the browser so I was at a loss of what was causing the issue. Pretty much everytime I worked on a post the “Content Recommendations”, “Related Articles”, “In-Text Links” and the “Tags” sections would be blank; They would show on screen but have no content on them. This pretty much render them useless. Because of that I couldn’t force myself to move to an SSL only WordPress backend.

Finally though I got tired of having to log-in every time I switched between the HTTPs and HTTP version of the site. I decided it was time to resolve this issue. I went in and digged through the HTML trying to understand what was going on: Was Zemanta not using https? Why is this not working.

To my dismay the answer was much simpler than I could had imagined. It turns out because Zemanta runs a script that is not part of this domain and does not travel via HTTPs, most browsers will block it. Take a look at Chrome for example:

Blocking this script made Zemanta unable to operate. This resulted as I mentioned on the different sections being present on the screen but unable to get content from the Zemanta servers.

The good news is just clicking on the Load unsafe script resolves the issue. Unfortunately neither Chrome or Firefox as far as I know let you chose which “unsafe” scripts to run. This could potentially present a security risk. I run my own WP install so I am assuming all the scripts I have are safe, but if you visit other sites you might have your doubts. It is even possible your site has been compromised and truly unsafe scripts are also being executed with scripts you want like Zemanta and there is no way to execute some and not all.

As far as I can see the Zemanta scripts are being blocked not because they don’t travel via HTTPs but because they are not part of the domain the website is on. I see their own domain name and Amazon’s domain as well. At this point there is little you can do if you want the message not to show up. One alternative is hosting your own versions of the scripts therefore having them load from your own server / domain avoiding chrome to consider them unsafe. This however could go against the terms of use of the third party scripts/components. If in doubt consult a lawyer. But if this is possible Google has a PageSpeed module for Apache and NginX that allows for third party components to be rewritten for your own domain with the aim of lowering DNS lookups and connections to more domains speeding up the site. You will see there they will also have a disclaimer that doing so could go against the terms of use of said code.