Download plugin from totalcmd.net "is a non secure connection"

[Peter]

When I try to download the plugin from totalcmd.net, the link behind "Download (x32, x64) (315 Kb)" is blocked by current Firefox because it "is a non secure connection". I can "accept the risk", but maybe it could / should be fixed.






Posts split from "DirSizeCalc 2.22 (content plugin)"-topic
viewtopic.php?t=18021

[petermad]

2Peter
Try and enter explicitly https://totalcmd.net in stead of just http://totalcmd.net or totalcmd.net in the addres line in your Firefox - http:/totalcmd.net does NOT automatically redirect to https://totalcmd.net

[Flint]

I guess it's more to do with the fact that the download link is set to http by the plugin author. totalcmd.net relies on authors to specify the correct links for downloading their plugins.

I must admit, the admin panel was created back in the days when nobody thought about HTTPS much, so it's not really helping the authors to tackle the whole http/https conundrum. If the author puts the http link, there's not much the site can do; it cannot magically know whether http can be safely replaced with https, or it will make the link invalid. And even if I add some kind of auto-check, there's no guarantee that https will remain working in the future (certificates can expire), or that http and https point to the same location (technically, http://example.com/file.zip and https://example.com/file.zip can point to completely different files).

[petermad]

2Flint

at least links to plugins that are stored on totalcmd.net or wincmd.ru itself (and I think that is the most) could be autodirected from http to https

Like I do on http://madsenworld.dk/tcmd

I don't know what kind of server totalcmd.net (and wincmd.ru) is on but if it is Apache based this code in the .htaccess file in the root:

Code: Select all

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

should result in redirection - so if you write totalcmd.net or http://totalcmd.net in the address field it will be redirected to https://totalcmd.net - also for all subdirectories.

Then if you want the user to be able to choose between http or https in a subdirectory you put this in the. htaccess file of that subdir::

Code: Select all

RewriteEngine on

I am no server expert at all - but this works for me.

[Flint]

2petermad
My belief is, if someone wants to use HTTP (there are lots of possible reasons for that), he/she should be able to. That's why I don't want to force all the visitors of totalcmd.net onto the HTTPS version.

I'm thinking about adjusting the author-supplied links on-the-fly, if they are totalcmd.net-based (that is, when I'm 100% sure they will work correctly in both versions). So on HTTP the link will remain HTTP, and on HTTPS it will be HTTPS. But I'll need some time to implement that.

[Peter]

2petermad
My belief is, if someone wants to use HTTP (there are lots of possible reasons for that), he/she should be able to. ...

The question is: How many authors are aware of this topic?

[Flint]

The answer to this question is obvious — very few. But I fail to see what point you are trying to make, exactly.

[Peter]

...But I fail to see what point you are trying to make, exactly.

I try to avoid this
viewtopic.php?p=408525#p408525
The standard-user types or clicks "totalcmd.net" - try to download - and will be confused because of some warnings - and maybe cancels the download. And I'm afraid that this will not be solved by itself.

[Flint]

As I said, for the links that point to totalcmd.net or one of the related domains, I'll change it, so the links would be using the matching protocol. For DirSizeCalc, for example, that will fix the issue. You just need to wait for a while, because I'm very busy at my work these days, and cannot find free time for implementing it right here and now.

But as for third-party domains, I simply have no control over them, and have to rely on authors to specify the link they consider to be the most appropriate. If that's an HTTP one, there's nothing I can do, because there are too many things that could go wrong if I simply replace it with HTTPS. One has to contact the author and discuss with him/her, whether an HTTPS link could be used instead.

[Peter]

OK, clear now for me.

[ghisler(Author)]

at least links to plugins that are stored on totalcmd.net or wincmd.ru itself (and I think that is the most) could be autodirected from http to https

I agree - I recently implemented this on ghisler.com on my own plugin page https://www.ghisler.com/plugins.htm for any plugins hosted on plugins.ghisler.com or www.totalcommander.ch.

[Dalai]

Well, I just tried to replace all HTTP links for my plugins with HTTPS links - and failed. The Author's Panel just says this when trying to save the change:

Code: Select all

The following problems occurrred while processing external links:

    https://wincmd.ru/files/9924350/wdx_CertificateInfo_0.3.0.rar:
    Failed to determine the file size. Please, check that the link is valid and points to file directly.

Back

I can open that link just fine in my browser.

So, it's not the plugin author's fault in this case.

2Flint
I hope you can fix this when you find some time for it.
BTW:

• the "Back" link in that error message is also broken.
• the function to upload files adds HTTP links by default which requires authors not just be aware of the issue but also manually change the link (if that even works, haven't tested it)
• the links in the "Plugin pages" of the Author's Panel also use HTTP

Regards
Dalai

[Flint]

2Dalai
Thank you for reporting this, I'll see what I can do. Unfortunately, at the moment I'm extremely busy, so I won't be able to fix it in the nearest future, but I'll get to it when I have some spare time.

[Flint]

Apologies for completely forgetting about it, and thank you for reminding in the other thread.

I have fixed the most important issues:
1. The author-provided https links using wincmd.ru domain should now work. It was a strange consequence of some network configuration; size detection worked fine with totalcmd.net links even with https, but not wincmd.ru.
2. Fixed the "back" link.

About the rest of your report: I still don't want to force all the users onto HTTPS, if no secret or personal data exchange is involved. Some people can use an old OS or browser version which have problems with modern certificates, so they cannot download by an HTTPS-only link. Therefore I prefer the approach when the download links use the same protocol as what the page was loaded with. However, the admin panel is not designed for such versatility. That's why I settled for using HTTP links as base, and converting them into HTTPS automatically when needed. I admit there are some disadvantages to that, and the approach is not the most intuitive for the authors, but at the moment I don't see a better solution, which would be easy enough to implement.

[ghisler(Author)]

I still don't want to force all the users onto HTTPS

I agree, and I do the same on ghisler.com. But I'm setting the following header:

Code: Select all

Content-Security-Policy: upgrade-insecure-requests;

This tells newer browsers to try https instead, but still returns the data with http.