Use HTTPS on site - Githubissues

tacsipacsi commented 6 years ago

After merging #22, WikiBlame should work on HTTPS too. As nearly everything on Wikimedia uses HTTPS, it would be nice if this one wouldn’t be an exception. Probably moving to Toolforge is an option if the current server can’t switch to HTTPS.

yfdyh000 commented 3 years ago

Any news?

FlominatorTM commented 3 years ago

Those are mainly comments in source files that are generated at Translatewiki. The remaining urls get forwarded to https automatically anyway, so I don't see the purpose of this. I'm sorry.

yfdyh000 commented 3 years ago

Those are mainly comments in source files that are generated at Translatewiki. The remaining urls get forwarded to https automatically anyway, so I don't see the purpose of this. I'm sorry.

We expect the https://wikipedia.ramselehof.de/wikiblame.php or something similar to works.

FlominatorTM commented 3 years ago

That won't be changed by the code changes. That will only work once I buy a "real" certificate for this subdomain. Where I consider it acceptable that your query gets transmitted in clear text, since there are no passwords involved etc.

yfdyh000 commented 3 years ago

That won't be changed by the code changes. That will only work once I buy a "real" certificate for this subdomain. Where I consider it acceptable that your query gets transmitted in clear text, since there are no passwords involved etc.

This can be changed through a free certificate like Let's encrypt or move to Toolforge. This is risky for public WIFI, VPN or proxy servers users.

tacsipacsi commented 3 years ago

The remaining urls get forwarded to https automatically anyway, so I don't see the purpose of this. I'm sorry.

They’re forwarded to HTTPS, but

Forwarding is another HTTP request, which means building up another TCP connection, sending the request, receiving the response and sending a bunch of ACK packets during this. This is avoidable time and transferred data.
One unencrypted HTTP request is well enough to conduct a man-in-the-middle attack and the user never arrives to the HTTPS version, or just for the Chinese government to log who reads about the Tiananmen Square protests. (When communicating over HTTPS, third parties see only the domain, not the path; while the whole request can be seen by someone intercepting the request in case of unencrypted HTTP).

FlominatorTM commented 3 years ago

Meanwhile a lot of the translation was changed to https at TranslateWiki. So if you fix the conflicts, I could merge your changes.

Meanwhile, there is also a version on ToolForge (see talk page for details): https://blame.toolforge.org/wikiblame.php

tacsipacsi commented 3 years ago

Conflicts fixed.

I think I’ve already tried blame.toolforge.org, but its output is buffered, in contrast to the one of wikipedia.ramselehof.de, which means the first bytes of the response arrive later and it’s more prone to time out.

FlominatorTM commented 3 years ago

Merged your changes. Maybe one could change something at Apache/nginx level over there?

tacsipacsi commented 3 years ago

I found https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Response_buffering on Wikitech.

FlominatorTM commented 3 years ago

Maybe one could tell MBH, who pushed blame.toolforge.org, to add that? https://de.wikipedia.org/wiki/Benutzer_Diskussion:Flominator/WikiBlame#Can_you_move_WikiBlame_to_Toolforge?

tacsipacsi commented 3 years ago

I think it doesn’t hurt if it’s added to the code in this repo (it’s just a few bytes per request), and then is MBH notified. This way it’s easier to update the Toolforge code in the future, and it’s less likely that this header is forgot during an update.

FlominatorTM commented 3 years ago

Well, actually ... https://github.com/FlominatorTM/wikiblame/blob/e6e17d8d84712ec685e7e94b0559ce84245ffa12/wikiblame.php#L11

tacsipacsi commented 3 years ago

I can’t test where is it broken, as it seems that nginx throws this header away:

$ telnet wikipedia.ramselehof.de 80
Trying 185.137.168.136...
Connected to wikipedia.ramselehof.de.
Escape character is '^]'.
GET /wikiblame.php HTTP/1.1
Host: wikipedia.ramselehof.de

HTTP/1.1 200 OK
Server: nginx
Date: Sat, 29 May 2021 23:20:58 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Surrogate-Control: BigPipe/1.0
Cache-Control: no-cache, must-revalidate
Vary: Host

1f6d
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
…

(This is your server, not the Toolforge one.) According to tools admin, you’re a maintainer of the Toolforge tool and should be able to become blame so that you can check if that line is actually in the code. If it is, it’s a bug that should be reported on Phabricator.

FlominatorTM commented 7 months ago

We now have https support on ramselehof.de as well

FlominatorTM / wikiblame

Use HTTPS on site #23