Task #2312
closed
Avoid serving web content over http:// when possible
Added by Guilhem Moulin almost 8 years ago.
Updated over 5 years ago.
Target version:
Team - Q3/2019
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 to Task #2340: LibreOffice download page - please change torrent file to be downloaded using https instead of current http link added
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 );
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
- 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
Maybe we can also making certain links hardcoded in this way:
<a href="//example.com#contents">see contents</a>
- Related to Task #1987: Please use HTTPS for downloads to protect users added
What's the status of this?
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.
- 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?
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.
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>, which
is now closed.
This ticket is 2312? ;-)
Meant https://redmine.documentfoundation.org/issues/2340, sorry :-P
Was there any progress recently, can you give a quick status update? ;-)
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.
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?
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?
- Target version changed from Q2/2018 to Q2/2019
Any updates on this topic?
- Target version changed from Q2/2019 to Q3/2019
Florian Effenberger wrote:
Any updates on this topic?
Any updates? Can this be closed, is this still pending? I don't think we have that many HTTP-only links?
- Status changed from New to Closed
Closing. We've chased http:// links out there and upgraded them by the ton. I guess there are still a handful of HTTP links left out there, and we'll keep upgrading them should anyone report them. Having HSTS deployed on the target vhost (#1086) also reduces a lot chances of cleartext/MiTM'able redirects.
Also available in: Atom
PDF
Updated by Florian Effenberger almost 6 years ago