decentraland / comms-gatekeeper / 31028807306

86%

main: 85%

Build Type

Pull #284

github

Committed by LautaroPetaccio

Commit Message

feat: match bans against the device an address is recorded on

the voice and cast gates added in the previous commit were address-only, because
no device identifier reaches those paths. that left the evasion case they were
meant to cover still open: a fresh wallet that already connected from a banned
device has that device in player_connection_info, so the record exists, but
nothing consulted it and the wallet still got a voice or cast token.

resolve the device term in getActiveBanForConnection instead of at each call
site. when the request supplies no device identifier, fall back to the device the
address was last recorded connecting from. one gate, so every enforcement path
gains this at once rather than voice and cast growing their own lookup.

a fallback rather than a union with the supplied identifier, deliberately:

- no extra query on the hot path when a device already arrives, and the supplied
  identifier stays authoritative for that connection.
- race-free against the connection-info upsert that runs concurrently on the
  token paths. the upsert COALESCEs a null incoming device onto the stored value,
  so a request supplying no device cannot clobber the row the gate reads,
  whichever lands first. a union would read the stored row even when a device
  arrives, and could see the previous device before the upsert commits, so a user
  who legitimately moved machines would be rejected intermittently.

this also closes coverage for a client that stops sending the identifier: going
quiet no longer sheds the device term, since a missing term matches nothing while
the recorded one still matches.

resolution failure is not fatal. the device term is supplementary, so a failed
connection-info read logs and falls through to the address match instead of
failing a gate the request did not depend on.

only the last recorded device is consulted. player_connection_info is one row per
address, so this covers the device a wallet most recently used, not every ... (continued)

Pull Request Pull Request #284: docs: record why ban status and token retrieval disagree on device bans

Coverage Stats

1130 of 1445 branches covered (78.2%)

Branch coverage included in aggregate %.

24 of 26 new or added lines in 5 files covered. (92.31%)

10 existing lines in 3 files now uncovered.

3103 of 3508 relevant lines covered (88.45%)

76.77 hits per line