Forum for all users to discuss the implementation and operation of the ChoralWiki at CPDL
Posts: 15
Joined: 04 Jul 2013 09:33

Postby AlexMyltsev » 24 Jun 2016 13:47


it seems that CPDL does not support HTTPS, even for the contributor wiki. An Apache webserver is listening on, but it just serves an error page. So contributors send their passwords over HTTP, like in 2005. It pains me to see this :-).

It should be pretty easy to get a free TLS certificate from and use it on, even if only for the contributor wiki. This should not take the administrator more than 20 minutes, and I'd volunteer to assist in the process (I have configured nginx to do this a number of times, it is straightforward).

We don't have to redirect people from HTTP to HTTPS at first, for fear of increased server load; the HTTPS option will just be there for the few security-sensitive contributors :-). Later, if the server load is acceptable, the login links can be changed to let everyone be more secure.

Posts: 1938
Joined: 22 Aug 2008 07:28


Postby vaarky » 06 Nov 2017 18:51

We're very sorry we overlooked replying on this. We have been and are continuing to work on this.

Posts: 15
Joined: 04 Jul 2013 09:33


Postby AlexMyltsev » 23 Jan 2018 21:35

vaarky wrote:We have been and are continuing to work on this.

As I mentioned back in 2016, setting up HTTPS is a matter of half an hour.

I can only repeat my offer: whenever an administrator of CPDL can spare an hour of his time, we can walk through the process together, step by step, and just make HTTPS work. My Telegram username is myltsev, my email is Non-working HTTPS is a shame in 2018, and I hope together we can overcome this deplorable situation.

Site Admin
Posts: 2593
Joined: 05 Mar 2006 19:57
Location: Rome, Italy


Postby choralia » 24 Jan 2018 16:14

AlexMyltsev wrote:As I mentioned back in 2016, setting up HTTPS is a matter of half an hour.

No, it's much more than that: traffic is distributed to multiple servers that use different technologies, and users should be transparently handled by all servers. Installing a certificate on a server is easy, however configuring the whole system to work consistently is not completely obvious. Our multi-server architecture may require some modification to work under https. We also have to modify some custom extensions, which were originally conceived to work under http only.

Preliminary tests have also revealed that the MediaWiki software version currently used (1.29) has a strange behavior related to the management of login/session cookies under https. The session storage has been changed since previous versions, and sometimes the mechanism to prevent session hijacking is unexpectedly triggered. This is very nasty as users cannot login then. This problem may be somehow emphasized by our multi-server architecture, so we have to be very careful before deploying https. Extensive testing is required.

Meanwhile, MediaWiki version 1.30 was released. Updating from version 1.29 to version 1.30 will require to perform the complete set of non-regression tests, too. So, it makes sense to perform the two activities (upgrade to version 1.30 and modifications/tests for https) altogether. We generally perform Mediawiki version upgrades during off-peak traffic periods (Christmas, Easter, or Summer), to minimize the impact of possible issues. So, the next reasonable target is Easter time. I'm afraid that you have to patient, and accept "this deplorable situation" a little bit longer...


Return to “Operation and Implementation issues”

Who is online

Users browsing this forum: No registered users and 1 guest