SSL support

Using a protocol relative URL here will fix that.

Using a protocol relative URL doesn't fix the issue because the hostname is different - ws.sharethis.com for ssl and w.sharethis.com for non-ssl. https://w.sharethis.com will work but it gives an error due to incorrect ssl certificates.

The patch in comment one misses references to the insecure urls in stlib_picker.js.

The new multi-post widget type has problems with ssl, the direct-post widget works ok.

Finally, a reminder that you'll need to clear all your caches in order for these changes to take effect.

With one minor tweak to Rob's patch you can use a protocol-relative URL.

//ws.sharethis.com/button/buttons.js answers to both http and https.

   $is_five = $data_options['widget'] == 'st_multi' ? 'true' : 'false';
   $publisher_id = $data_options['publisherID'];
   $st_js = "<script type='text/javascript'>var switchTo5x=$is_five;</script>
-    <script type='text/javascript' src='http://w.sharethis.com/button/buttons.js'></script>
+    <script type='text/javascript' src='//ws.sharethis.com/button/buttons.js'></script>
     <script type='text/javascript'>stLight.options({publisher:'$publisher_id'});</script>";
   return $st_spans . $st_js;
 }

This also works for the main ShareThis library at //ws.sharethis.com/share5x/js/stcommon.js.

Although //ws.sharethis.com works, it isn't really documented on their API, so I think a check like dedisoft suggested is a good idea. Committed http://drupalcode.org/project/sharethis.git/commit/d78fd33

Just adding a comment here if somebody else will have the same issue as I have right now. Current HTTPS check doesn't work if SSL is installed on a load balancer (or reverse proxy) in front of the server, but not on the server itself. In this case $_SERVER['HTTPS'] is not set and plugin serves JS from a HTTP connection, resulting in a browser warning. I'd suggest switching to a protocol relative URL, but ShareThis has different domains for a HTTP/HTTPS requests - w.sharethis.com vs ws.sharethis.com.

I don't see an ideal solution here, but for now switched to a protocol relative URL that points to a secure domain - //ws.sharethis.com/...

Indeed, let's add support for such proxies.

I updated my version of ShareThis to the most recent version (7.x-2.12) but I am still getting mixed content / insecure warnings on pages that have the ShareThis widget on them, as well as the site homepage:

Loading mixed (insecure) display content "http://image2.pubmatic.com/AdServer/Pug?vcode=bz0yJnR5cGU9MSZjb2RlPTMyND..." on a secure page [Learn More]

I managed to find this in the source in an iframe:
<iframe name="stSegmentFrame" width="0" height="0" id="stSegmentFrame" src="https://seg.sharethis.com/getSegment.php?purl=https%3A%2F%2Fwww.fosterclub.com%2F&amp;jsref=https%3A%2F%2Fwww.fosterclub.com%2Fsafety-policy&amp;rnd=1437092891329" frameborder="0" scrolling="no" style="display: none;"></iframe>

It contains the following:

<script type="text/javascript">var ifr=document.createElement("iframe");ifr.frameBorder=0;ifr.scrolling="no";ifr.width=1;ifr.height=1;ifr.src="//ads.pubmatic.com/AdServer/js/user_sync.html?p\x3d57792\x26predirect\x3dhttp%3A%2F%2Fimage2.pubmatic.com%2FAdServer%2FPug%3Fvcode%3Dbz0yJnR5cGU9MSZjb2RlPTMyNDEmdGw9MTI5NjAw%26u%3D";document.body.appendChild(ifr);</script>
<iframe width="1" height="1" src="//ads.pubmatic.com/AdServer/js/user_sync.html?p=57792&amp;predirect=http%3A%2F%2Fimage2.pubmatic.com%2FAdServer%2FPug%3Fvcode%3Dbz0yJnR5cGU9MSZjb2RlPTMyNDEmdGw9MTI5NjAw%26u%3D" frameborder="0" scrolling="no"></iframe>

Buried deep within this iframe is the insecure image:
<img src="http://image2.pubmatic.com/AdServer/Pug?vcode=bz0yJnR5cGU9MSZjb2RlPTMyNDEmdGw9MTI5NjAw&amp;u=2632FCEC-BA5E-4007-9FE1-51DDD799D5AD">

How can I resolve this?

Does drupal_add_js('//sharethis...') not work?

Hi jlea9378 , after looking through sharethis module code, it's including sharethis.com javascript in https when required, the problem likely isn't in this module, likely a problem upstream at the sharethis.com where the javascript is loaded from. At least thats what it looks like to me. There might be a way to force https for urls loaded from third party js scripts , like modify the js on the fly as its loaded from that site so that all img src is forced to https , but it might be easier just to file an issue at sharethis.com and mention this to them. I wouldn't be surprised if this is already fixed as we speak, might want to check it again, next step would be to contact sharethis.com directly I think.

Hi There,

Thanks for your patience here! We've made some changes in our support organization and we're working through responding to these. We've added SSL support for Drupal module as a feature request for our team to review!

Best
ShareThis Support

Feature request? Weird, should be standard... Found this document about SSL connection to Sharthis.

http://support.sharethis.com/customer/portal/articles/475097-ssl-support

@ShareThisSupport - SSL Support is already enabled on Drupal and all your implementations. If you had bothered to read, you would see that @jlea9378 has a problem with your code loading insecure images.

@netgeek123 this is already implemented. The problem isn't in the Drupal module. It's on their side. The problem has been reported on their support pages.

I too have this problem.

Googling for "sharethis loading insecure image" will do the trick. Here's an example of a recent report of this http://support.sharethis.com/customer/portal/questions/12990891-sharethi...

To anyone future readers, you will face intermittent issues with sharethis scripts loading insecure content, no matter what you do. Whether you use late load, or not. Even if your server is correctly configured, and you (as I have) check that the resources from sharethis are being loaded over https and through ws.sharethis.com (as they list on the instructions on their site).

This is because their scripts are loading http images / tracking pixels. Until they fix the issue that is, which they've been dismissing for years now.

-----

@ShareThisSupport When I switch to incognito/private mode, or clear all my cookies, the issue is fixed. This tells me that your (or your partners') tracking code are loading insecure images/ resources/ tracking pixels depending on the user. Hence be careful when dismissing this issue, since it might be hard to replicate.

---

My two cents. Switch away from ShareThis until this is fixed. Especially for ecommerce sites.

I totally realize it was not the issue of the thread. :)

Just seems really weird that they would not fix such a small problem really.

Yes. It's definitely on them. Hopefully they figure it out eventually. I have a feeling that they have to get their behavior tracking partners to make changes, hence why they're slow to figure it out.

@stupiddingo and @drupalninja99 both mentioned a working solution.
What is holding this issue back to implement a protocol relative url?

@aoturoa There's no patch needed. Not a module issue. The issue is that their script (loaded through https), was (and probably still is) loading http resources.

I can confirm that the patch in #20 works with version 2.13 and resolves HTTPS issues with the buttons.js file. If it didn't work in the past, it's possible sharethis.com made some more recent updates to fix the issue based on the following https://www.sharethis.com/support/legacy/moving-from-http-to-https-ssl-s....

Please reconsider this change.

+1

@galeaspablo this seems pretty straightforward- why not roll this into the module?

Can one of the maintainers give this attention?

patch #20 works for me