Project

General

Profile

Task #2312

Avoid serving web content over http:// when possible

Added by Guilhem Moulin over 1 year ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Category:
Webserver
Target version:
Team - Q2/2018
Start date:
Due date:
% Done:

0%

Estimated time:
Tags:
URL:

Description

Ideally all http:// requests would be permanently redirected to their https:// counterpart. It's mostly the case already (using X.509 certs from Let's Encrypt), but the TDF and LO websites are still serving pages over http://. (There is an HTTPS Everywhere rule for both, but we still want 301 redirects on our HTTPd.)

Moreover we should track down pages that are still referencing http:// URIs (for instance the imprint or the logo, respectively with an <a> and <img> tag) and upgrade them to https://.

In some cases it makes sense not deploy that redirect, though:

Related issues

Related to Infrastructure - Task #2340: LibreOffice download page - please change torrent file to be downloaded using https instead of current http linkClosed

Related to Infrastructure - Task #1987: Please use HTTPS for downloads to protect usersIn Progress

History

#1 Updated by Guilhem Moulin about 1 year ago

  • Related to Task #2340: LibreOffice download page - please change torrent file to be downloaded using https instead of current http link added

#2 Updated by Olivier Hallot about 1 year ago

Hi

I grep'ed the source code sfx2 module and FWIW, here is the result WRT to hub.libreoffice.org. I think nothing is to change

tdf@olivier-ntbk:~/git/core/sfx2/source$ git grep hub
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/send-feedback/?LOversion=" + utl::ConfigManager::getAboutBoxProductVersion() +
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/forum/?LOlang=" + aLang);
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/documentation/?LOlocale=" + utl::ConfigManager::getLocale());
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/donation/?BCP47=" + aBcp47 + "&LOlang=" + aLang );

#3 Updated by Krasnaya Ploshchad’ about 1 year ago

To avoid this, I have installed Smart HTTPS add-on in my browser, then I enabled “Add Upgrade-Insecure-Requests header to ALL websites with HTTPS protocol” option. All requests would be forced using HTTPS firstly.
https://mybrowseraddon.com/smart-https.html

#4 Updated by Florian Effenberger about 1 year ago

  • Target version changed from Q3/2017 to Q4/2017

Given the other pending tasks for Q3 (e.g. further SSO deployments), and that this is a longer tasks, shifting to Q4
Olivier, if there are pages that are important for you specifically wrt. SEO, please let us know, and Guilhem can look if those can be prioritized

#5 Updated by Krasnaya Ploshchad’ about 1 year ago

Maybe we can also making certain links hardcoded in this way:

<a href="//example.com#contents">see contents</a>

#6 Updated by Guilhem Moulin 11 months ago

  • Related to Task #1987: Please use HTTPS for downloads to protect users added

#7 Updated by Florian Effenberger 8 months ago

What's the status of this?

#8 Updated by Guilhem Moulin 8 months ago

All URLs on the main sites (LO's and TDF's), as well as on the NL template, should have been upgraded to https://, with the exception of those to http://download.documentfoundation.org. The NL sites weren't touched yet.

As for download.documentfoundation.org, we want to leave the mirrors alone for now but upgrade URLs to small files (.mirrorlist/.info/.torrent, which we serve ourselves). The SS3 template is using a single variable with the URI path, but in principle we could use "//download.documentfoundation.org" and prepend "http:" to the "normal" download URL (so all other URLs will preserve the scheme, namely https://). Not sure what the side-effects of doing that could, so I need to sync with cloph first.

#9 Updated by Florian Effenberger 7 months ago

  • Target version changed from Q4/2017 to Q2/2018

All URLs on the main sites (LO's and TDF's), as well as on the NL template, should have been upgraded to https://, with the exception of those to http://download.documentfoundation.org. The NL sites weren't touched yet.

How much work would the NL sites entail?
Can we send out a notice we will do this via a script in xyz days, and people should check the pages afterwards?
HTTPS also helps our SEO efforts...

As for download.documentfoundation.org, we want to leave the mirrors alone for now but upgrade URLs to small files (.mirrorlist/.info/.torrent, which we serve ourselves). The SS3 template is using a single variable with the URI path, but in principle we could use "//download.documentfoundation.org" and prepend "http:" to the "normal" download URL (so all other URLs will preserve the scheme, namely https://). Not sure what the side-effects of doing that could, so I need to sync with cloph first.

Any outcome of this already?

#10 Updated by Guilhem Moulin 7 months ago

Florian Effenberger wrote:

All URLs on the main sites (LO's and TDF's), as well as on the NL template, should have been upgraded to https://, with the exception of those to http://download.documentfoundation.org. The NL sites weren't touched yet.

How much work would the NL sites entail?
Can we send out a notice we will do this via a script in xyz days, and people should check the pages afterwards?
HTTPS also helps our SEO efforts...

Would certainly be easier if we had a robot do the mass edit. No idea how to do that though, and I didn't find hints online at the time, so I wrote a small webcrawler to detect upgradable http:// links, and edited by hand… took a full night, so I stopped after the non-localized sites and the NL template. Not trilled to do that again on the localized sites I must say, and I fully understand if translators feel the same way. I'd gladly learn how to perform mass edition if that's possible.

As for download.documentfoundation.org, we want to leave the mirrors alone for now but upgrade URLs to small files (.mirrorlist/.info/.torrent, which we serve ourselves). The SS3 template is using a single variable with the URI path, but in principle we could use "//download.documentfoundation.org" and prepend "http:" to the "normal" download URL (so all other URLs will preserve the scheme, namely https://). Not sure what the side-effects of doing that could, so I need to sync with cloph first.

Any outcome of this already?

It was #2312, which is now closed.

#11 Updated by Florian Effenberger 7 months ago

Would certainly be easier if we had a robot do the mass edit. No idea

Would that be possible via SQL statements? I think Cloph mentioned
something like that.

It was #2312 <https://redmine.documentfoundation.org/issues/2312&gt;, which
is now closed.

This ticket is 2312? ;-)

#12 Updated by Guilhem Moulin 7 months ago

Florian Effenberger wrote:

Would certainly be easier if we had a robot do the mass edit. No idea

Would that be possible via SQL statements? I think Cloph mentioned
something like that.

Possibly, I need to check if the table has rows with the full pages, or if it's just the diff. In the latter case the risk of database surgery causing corruption is much higher…

It was #2312 <https://redmine.documentfoundation.org/issues/2312&gt;, which
is now closed.

This ticket is 2312? ;-)

Meant https://redmine.documentfoundation.org/issues/2340, sorry :-P

#13 Updated by Florian Effenberger 5 months ago

Was there any progress recently, can you give a quick status update? ;-)

#14 Updated by Guilhem Moulin 5 months ago

We have 301 redirections to https:// everywhere except for the hub and the URL shortener (pointless to have double redirects) and the mirrorbrain instances. So technically this ticket can be closed.

On the other hand we still have hard-coded http:// links in various places, for instance on Silverstripe (NL sites) and on the wiki. Perhaps we should file other tickets for that.

#15 Updated by Florian Effenberger 5 months ago

On the other hand we still have hard-coded http:// links
<http://%20links> in various places, for instance on Silverstripe (NL
sites) and on the wiki. Perhaps we should file other tickets for that.

Can you send a list where we still have those links, so we can
distribute the task amongst the team to fix these?

#16 Updated by Florian Effenberger about 2 months ago

Can you send a list where we still have those links, so we can
distribute the task amongst the team to fix these?

Any updates?

Also available in: Atom PDF