Thinklab Meta [meta]

Support (and enforce) ssl connections to Thinklab

The web is a dangerous place, and I find it a little surprising that Thinklab doesn't have support for ssl (https:// connections).

There are a few ways to go about this, but a quick and efficient one is to use the free SSL proxy of the amazing Clouflare.

If you want your own certificate, they now come free and quick thanks to the new Let's Encrypt certificate authority. Here is a one-page shortcut if you know how to generate certificates.

I've been researching this for a while and I'm really unclear on what the best option is. If it's not a big deal I prefer to defer this until later. I do not know how to generate certificates.

I think this is really important. Furthermore, I don't think it should be difficult (anymore), as a lot of services are here to help.

Beyond protecting the privacy of your users, ssl has many advantages, like officially improving your google ranking.

I might not have been clear but here are your two options:

  • You rely on a third party, your dns provider for instance, to encrypt the connection between the client (us) and their servers. The rest is unencrypted but it's not an issue. I know cloudflare lets you do that, and it's free — see there.

  • You request the ssl certificate and install it yourself. The first step should be straightforward, as any ssl certificate provider has an easy-to-follow tutorial. Your domain provider will often propose to create a ssl certificate for you, even for free. The installation of the ssl certificate can be a little trickier, depending on your webserver stack, but unless you have some very special technologies at work, you will find a tutorial out there. Just for Django, there are many.

Here is a recent analysis that saw an appreciable correlation between SSL and Google rank.

Obviously, this may be only a correlation rather than causation. Nonetheless, HTTPS sends a powerful symbol of authority, credibility, foresight, and best practice. For example, PeerJ has it, while most of the others do not.

Beyond the reasons for google rank, it's extremely easy to snag passwords/email addresses over open wifi connections (or any point between the user and your server). If you don't have SSL, it's generally just easier to think of user accounts (and passwords) as disposable.

  • Antoine Lizee: I agree - the google ranking or PR attached to using https is not significant in comparison to the security problems that are mitigated with encryption of connections.

@alizee I am trying to setup the CloudFlare SSL Flexible option. CloudFlare says it is active but does not work. I have no idea what to do. Any suggestions?

And here's what CloudFlare says about their Flexible SSL option:

Flexible SSL: secure connection between your visitor and CloudFlare, but no secure connection between CloudFlare and your web server. You don't need to have an SSL certificate on your web server, but your visitors still see the site as being HTTPS enabled. This option is not recommended if you have any sensitive information on your website. It should only be used as a last resort if you are not able to setup SSL on your own web server, but it is less secure than any other option (even “Off”), and could even cause you trouble when you decide to switch away from it: How do I fix the infinite redirect loop...

It doesn't exactly give me confidence I'm going down the right path.

What it is doing is encrypting traffic between the user and cloudflare. If the user is in a place with open wifi, it won't be possible to sniff the password (right now that's trivial). Anyone with a router between the CloudFlare server and your server can still lift the info.

For a user in a coffee shop, this is helpful. For a malicious router - the passwords/email addresses are still at risk.

  • Antoine Lizee: This is correct. I would also add that using Cloudflare's 'Flexible SSL' doesn't prevent you from adding your own certificate later in order to secure the second part of the interaction. works for me. It just looks like several elements fail to load because they specify HTTP rather than HTTPS. See for example:

 <script src=""></script>
 <script src=""></script>
 <script src=""></script>

I believe the best practice is to link to all external resources that support SSL using HTTPS. For internal resources, you can use protocol relative URLs or HTTPS. These steps should make the website render fully.

Thanks Casey.. that's about as much as I actually understand. How to get it actually setup is another matter. Seems like most all articles on the web are related to using this with Wordpress. And this again, makes me feel I'm not going with the best solution.

How to get it actually setup is another matter.

SSL via CloudFlare is working currently is it not?

And this again, makes me feel I'm not going with the best solution.

The best solution is to get an SSL certificate for Thinklab. I did that for my Piwik server, and it was difficult since I have no web admin skills, but ultimately doable and free.

Looks like SSL is mostly operational. Cheers!

The MathJax import still needs to be updated:

<script src=""></script>

Finally, auto-generated Thinklab links should use HTTPS? @alizee how do you recommend making it so the coffee shop user doesn't unwittingly use HTTP. Should the DOI metadata be updated to specify HTTPS?

On an unrelated note, both Twitter and DOI resolution support HTTPS, so it would be nice to update these out-links.

Hey guys I'm confident I can handle things from here. The https wasn't working on my home internet but was working on my cell phone so may have been a propagation issue. We will force HTTPS as the only way to access the site. Non secure urls will forward to secure ones

Okay this should all be working now. Thanks for bringing the importance of the issue to my attention. Let me know if you notice any problems.

Sorry for the lack of responsiveness before - this is awesome, thanks @jspauld! In 3 years of using them, I yet have to be disappointed by Cloudflare - I'd say you went the right path.

Status: Completed
  Technical Issue
Referenced by
Cite this as
Antoine Lizee, Jesse Spaulding, Daniel Himmelstein, Casey Greene (2016) Support (and enforce) ssl connections to Thinklab. Thinklab. doi:10.15363/thinklab.d197

Creative Commons License