Skip to content

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

Description

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 Changed file to run in Linux to proper file #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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions