Support for HTTP links.

[Neo2003]

Aknowledgements

• [X] I have checked that there's no other issue describing the same or similar problem that I currently have, regardless if it has been closed or open.

• [X] I can confirm that this is not an issue with the Discord website, but it is a problem specific to the WebCord itself. I have tested if this bug occurs on Chromium/Chrome or any other Chromium-based browser that uses unpatched/upstream Chromium engine.

• [ ] I have tried running the build from the master branch and it does not have any fixes implemented according to my issue.

• [ ] My issue describes one of the unstable and/or not fully implemented features.

• [ ] I have found a workaround to mitigate or temporarily fix this issue in affected releases (please write it in Additional context section below).

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

v19.0.10

Application version

v3.6.0

Bug description

http:// links do not open, no reaction. They work in real and bad official discord client. Workaround, copy link address and paste it in a browser.

Additional context

I think the description is obvious.

[Jai-JAP]

This may be the problem https://github.com/SpacingBat3/WebCord/blob/d8d88a9a7e08138329212096539aa85c2c3f0751/sources/code/common/global.ts#L77

[SpacingBat3]

This is actually an expected behavior – WebCord does not open any unsecure links. In WebCord, everything is enforced to HTTPS and anything that uses unsecure protocol is simply blocked.

[SpacingBat3]

That being said, images, videos, scripts etc. from http: should also be blocked.

[SpacingBat3]

The question is: is there ANY reason why to keep HTTP links as supported? It feels like it is a bad idea and probably is from the security point of view. In the modern world HTTPS confirms that specific domain is legitimate (DNS can't lie to us) and prevents from attacks that uses protocol downgrade to escape cerficate verification. And sure, browser nowadays does some job to prevent this but WebCord actually does not know which app opens specific URL, so it is unsure whenever your browser cares about the security or not.

This is why I want to keep it as it is.

[Neo2003]

Yes, there is some reason to keep HTTP. Some small sites do not use https. Here an exemple link: http://christophe.bray.free.fr/informatique/falcon/Atari%20Falcon%20030%20versus%20Amiga%201200.pdf There should at least be an option to allow it. I don't want to build it just to for that, but I may need to if this is only WebCord/sources/code/common/global.ts and you don't understand user need to choice instead of enforcing blindly.

[SpacingBat3]

Yes, there is some reason to keep HTTP. Some small sites do not use https. Here an exemple link: http://christophe.bray.free.fr/informatique/falcon/Atari%20Falcon%20030%20versus%20Amiga%201200.pdf There should at least be an option to allow it. I don't want to build it just to for that, but I may need to if this is only WebCord/sources/code/common/global.ts and you don't understand user need to choice instead of enforcing blindly.

I think I can actually make those links clickable while preserving everything safe. In scenario HTTP link would be opened, WebCord would just ensure if it is you who clicked this link by showing up a dialog window. I'll enforce this new behaviour for HTTP sites – there will be no option to disable it, but HTTPS sites will be still opened with the current policy (only show dialog if user allows for doing that and origin is different from the current instance link's origin). This is to actually mimic how browsers work in HTTP-only mode.

You should also know that Electron is also responsible for blocking HTTP, as it doesn't trust insecure content on secure sites (i.e. HTTP stuff does not load on HTTPS). I'm not going to change this for the security reasons.