You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
The Socket.IO connection never establishes — the page sticks on "Loading"
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:
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.
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:
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:
Affected source files and endpoints:
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}:${BAfetch(
${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.