Repository navigation
A game's results are only written for the people it was sent (v1.2.1) - #75
Merged
Merged
Conversation
The second of the two follow-ups the security review left: the receiver took player.user_id from a signed delivery and, for an account with no row, made one - and an approved event_invites row beside it, which is what decides who can see a private event and its guest list. Reaching that meant being the FinalTable server the table was handed to, so nothing here was open to a member; it is closed because a receiver should record a night, not extend the guest list. The guest list that goes with a game is now kept on finaltable_games.roster when the table is set up, and $playerOf - the one place every event resolves a player - refuses an id that was never on it. FinalTable has no route to amend a guest list after creation and its engine turns an off-list player away at the door, so the stored list and its roster cannot drift. NULL means a game set up before the column existed: do not check, or a table already running would stop recording. That fallback can go a release later. Refusals are collected and written to the activity log once per delivery, however many names a standings list carries - a crafted completion should not be able to fill the log with one event. The other follow-up needed no code. Hide guest list binds the guest list on the event page, not the watch link: the rail is pass-on-able by design on both sides, every invitee already has the link by email, and a watcher sees the field by name and never a card. DOCS.md says so where a host reads it, and SECURITY.md records why it was decided that way rather than gated. Proven on the dev pair with real signed deliveries: an on-roster result landed, an off-roster invitee's was refused, a completion naming three strangers created no players and no invites, and each left one warning line. All six sweeps clean, the double-dispatch one with the panel rendering. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Security
When a table is set up on FinalTable, the guest list that goes with it is
now kept beside the game, and the receiver writes bust-outs, re-entries and
finishing places only for accounts on it. Before this, a delivery naming
somebody who had never been invited would have made that account a player
in the session and given it an approved invite to the event — which is what
decides who can see a private event and its guest list. Reaching that took
being the FinalTable server the table was handed to, so nothing was open to
a member here; it is closed because the receiver should record a night, not
extend the guest list. Ids that were never sent are refused and written to
the activity log once per delivery, however many a standings list names. A
table set up before this release keeps recording as it did.
Changed
guest list covers the guest list on the event page; the watch link is
pass-on-able by design — the invitation email tells every invitee as much,
and somebody on the rail sees the field by name and the chip counts, never
anyone's cards. Nothing behaves differently; the documentation stops
leaving the question open.
🤖 Generated with Claude Code