Spent a real debugging session chasing a "not matching configuration"
error assuming it was host mode, when it was actually guest PKCE mode
hitting a redirect URI (production, root path) that was simply never
registered — the README only documented the two local dev URIs, not
that host mode and guest mode each need their own entry per
environment (four total), and gave no way to tell which flow's
request was actually failing.
Added the full four-URI table and a note to check the browser's actual
address bar at the point of failure — the error message is identical
regardless of which flow's redirect_uri didn't match.
Was a Vite build-time env var, requiring a second copy of a non-secret
value as a separate Gitea CI secret alongside the one already in .env
for the api service. Client id isn't sensitive (public in every
Spotify authorize URL), so it doesn't need build-time baking at all —
now fetched once from a new GET /api/config on the already-running api
server, cached client-side after the first call.
Collapses config back down to the one place it already lived
(the deploy host's .env / docker-compose environment), removes the
CI build-arg and its secret entirely.
Verified end-to-end: /api/config returns the real client id, and a
live guest-login click correctly carries it through into the actual
Spotify authorize URL (decoded and checked, not just assumed from the
code).
Based on bingo-bango by f8al (MIT) — same core card-generation idea
("both facets": a square is either an exact song title or an artist,
and an artist square lights up on any of their tracks), reworked with
a real host/guest split, live multiplayer sessions, and cover-art
squares. f8al credited in the footer, README, and PROPOSAL.md.
Three ways to play: host a live session (server-side Spotify
connection, join code + QR, caller screen, auto-call from real
playback), join someone else's session (no login needed), or solo
(guest PKCE login or a pasted public playlist URL, one-off card).
Genuinely verified against a real Spotify account throughout, not
just built and assumed working — including two real bugs found and
fixed along the way (Spotify's playlist-tracks endpoint quietly
renamed to /items with a reshaped response; reading playlist tracks
needs real user auth even for public playlists, so the "no guest
login" public-playlist path routes through the host's connection
instead of a dead-end app-only token). Both Docker images built and
run together on a real network with the nginx proxy verified working
end-to-end, and auto-call confirmed detecting an actual track playing
live through Spotify Connect within one poll tick.
