Scoreboard breaks when accessed via HTTPS reverse proxy (mixed content — hardcoded ws:// and http://)

I run TSH behind a Cloudflare Tunnel so I can control scoreboards remotely at events (from a tablet or phone on a different network). When accessing the scoreboard page via the tunnel (https://), two things break:

1. The Socket.IO connection never establishes — the page sticks on "Loading"
2. Even after fixing #1, all interactive features do nothing — scores don't submit, bracket doesn't load, player data doesn't update

Affects all browsers (Chrome, Safari) — it's a protocol issue, not browser-specific.

Root cause:

The scoreboard frontend hardcodes ws:// and http:// regardless of what protocol the page was loaded over. When the page is served via HTTPS, the browser enforces Mixed Content security rules and silently blocks both:

• The ws:// WebSocket connection
• Every fetch("http://...") call in the app

Affected source files and endpoints:

• stage_strike_app/src/websocketConnection.t://)
• stage_strike_app/src/ScoreboardPage/Score.jsx — submitScore (/score), submitSetInfo (/scoreboardN-set?)
• stage_strike_app/src/ScoreboardPage/Team.j/scoreboardN-set?,/scoreboardN-update-team-*)
• Clear Scoreboard button — /scoreboardN-cle
• Swap Teams button — /scoreboardN-swap-teams
• Get Sets — /get-sets (Start.gg bracket pul
• Load Set — /scoreboard1-load-set
• Stage Strike RPS — /stage_strike_rps_win
• Player autocomplete — /states?countryCode=
• Countries data — /assets/data_countries.js

Suggested fix:

Check window.location.protocol at runtime anon HTTPS, omitting the port (the reverseproxy handles routing). Fall back to ws:// / http:// with the port on plain HTTP (LAN access).

For the WebSocket:
const wsUrl = window.location.protocol === "
? wss://${window.location.hostname}/
: `ws://${window.location.hostname}:${BACK
this._instance = io(wsUrl, { ... });

For all fetch calls — replace:
fetch(http://${window.location.hostname}:${ With: const base = window.location.protocol === "h ? https://${window.location.hostname}:http://${window.location.hostname}:${BA
fetch(${base}/endpoint)

A shared helper function for the base URL would clean this up across all components.

Why this matters:

Tournament operators running multi-table setups often need remote scoreboard access from phones or tablets that aren't on the same LAN. A Cloudflare Tunnel (or anyer HTTPS) is a natural and common solution,but it's completely blocked by the current hardcoded protocols. This fix would make TSH fully functional in those setups — including bracket loading from Starand all scoreboard controls — withoutrequiring manual edits to compiled output files after every update.

Start by inspecting stage_strike_app/src/websocketConnection.t and the fetch calls in stage_strike_app/src/ScoreboardPage/Score.jsx and Team.j. Trace the listed scoreboard, player, country, and bracket endpoints, then verify that WebSocket and fetch connections work through HTTPS while preserving plain-HTTP LAN access.