decentraland / comms-gatekeeper / 31024526913

86%

main: 85%

Build Type

Pull #284

github

Committed by LautaroPetaccio

Commit Message

feat: enforce platform bans on voice and cast token issuance

a platform ban was only checked on two of the wallet-scoped token paths, scene
comms and private messages. voice chat and cast issued livekit credentials with
no ban check at all, so a banned user kept full audio access through private
calls and community stages, and could still watch streams and mint new stream
keys. social-service-ea does not check bans either, so nothing upstream covered
the voice routes.

enforce the gate in the voice and cast logic components rather than in each
handler, so it holds for every entry point that reaches credential issuance and
matches the existing scene-ban precedent inside generateWatcherCredentialsByLocation:

- private voice chat: refuses the whole call when either participant is banned.
  issuing credentials only to the unbanned party would leave them alone in a
  room nobody can join.
- community voice chat: refuses join and create. a community role, owner
  included, does not override a platform ban.
- cast watcher token: checked before the location is resolved, so an
  unresolvable place still rejects.
- cast stream link: checked before the scene admin lookup, so the rejection
  never doubles as an admin-status oracle.

address-only on purpose. voice routes are called by the social service with a
bearer token and cast requests carry no device identifier, so no signed-fetch
metadata reaches these paths. getActiveBanForConnection is still the gate asked,
since it degrades to an address match without a device id and picks up device
coverage for free if one ever arrives.

the two key-bearer cast paths, streamer-token and presentation-bot-token, stay
unenforced because they authenticate a streaming key rather than a wallet and
have no identity to match. blocking the mint is what covers them: a banned admin
cannot obtain a new key, but a key minted before the ban keeps working until it
expires. recorded in the architecture notes instead of being papered ... (continued)

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

Coverage Stats

1125 of 1440 branches covered (78.13%)

Branch coverage included in aggregate %.

16 of 18 new or added lines in 5 files covered. (88.89%)

26 existing lines in 4 files now uncovered.

3096 of 3501 relevant lines covered (88.43%)

76.46 hits per line