https://cpdl.org

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

https://cpdl.org

Post by AlexMyltsev »

Hi,

it seems that CPDL does not support HTTPS, even for the contributor wiki. An Apache webserver is listening on cpdl.org:443, 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 letsencrypt.org and use it on cpdl.org, 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.
vaarky
Moderator
Posts: 2163
Joined: 22 Aug 2008 07:28

Re: https://cpdl.org

Post by vaarky »

We're very sorry we overlooked replying on this. We have been and are continuing to work on this.
AlexMyltsev
Posts: 15
Joined: 04 Jul 2013 09:33

Re: https://cpdl.org

Post by AlexMyltsev »

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 a.myltsev@gmail.com. Non-working HTTPS is a shame in 2018, and I hope together we can overcome this deplorable situation.
choralia
Site Admin
Posts: 2924
Joined: 05 Mar 2006 19:57
Location: Rome, Italy
Contact:

Re: https://cpdl.org

Post by choralia »

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...

Max
choralia
Site Admin
Posts: 2924
Joined: 05 Mar 2006 19:57
Location: Rome, Italy
Contact:

Re: https://cpdl.org

Post by choralia »

choralia wrote:the next reasonable target is Easter time
Unfortunately there was no time enough to implement and test the upgrade to MediaWiki version 1.30. However, it was possible to apply the modifications required for running https on the multi-server architecture.

SLL certificates are now installed on all servers, which are enabled both for http and https. Unless the user manually enters http or https on a given server, logged-in users will be normally served in https by the contributor wiki (www), while anonymous users will be normally served in http by the visitor wikis (www0, www1, www2 and www3). This server hosting the forums is also enabled for https (I'm using https right now).

It is possible that some internal links are hard-coded in http, and therefore a "mixed content" warning is displayed when running in https. For example, I've recently found that the Llypond icon had a hard-coded http link inside, so I had to correct it in order to get rid of the "mixed content" warning. Similar tweaks may be occasionally required until all http hard-coded links are fixed.

Max
vaarky
Moderator
Posts: 2163
Joined: 22 Aug 2008 07:28

Re: https://cpdl.org

Post by vaarky »

At some point, can we search programmatically for pages with hard-coded http:// links and auto-replace them?
Claude_T
Moderator
Posts: 609
Joined: 13 Jan 2007 15:16
Location: Fontenay-sous-Bois (France)
Contact:

Re: https://cpdl.org

Post by Claude_T »

I removed/replaced all (29) occurrences of 'http://www.cpdl' found through 'Special:Replace text' page, on our pages.
Don't know if some other remain, more deeply hidden.
Locked