decentraland / comms-gatekeeper / 31103830479

86%

push

github

fix: stop publishing the ban device id on the public status route (#286)

* fix: stop publishing the ban device id on the public status route

GET /users/{address}/bans is unauthenticated and returned the full ban record,
including bannedDeviceId. that value is a stable cross-wallet machine identifier:
two banned addresses carrying the same one are publicly linkable as one machine,
and a banned wallet querying itself learns its device was captured.

strip it from that response only. the record is otherwise unchanged, matchedOn
still reports whether the match came from the address or the device, and
enforcement is untouched — a test pins that the device still rejects a connection
after the field stops being shown, so this is presentation, not coverage.

moderators keep the value on the moderator-gated GET /bans, which is now the only
route that exposes it; a test pins that too.

openapi splits PublicUserBan from UserBan rather than letting the public operation
advertise a field it never returns.

requires decentraland/moderation-center#15 to ship first: its user moderation page
read banStatus.ban.bannedDeviceId from this route to render the Device row.

* docs: define the public ban schema standalone instead of subtracting a field

PublicUserBan was allOf UserBan with bannedDeviceId: not: {}. the intent is valid
openapi, but 3.0 renderers and generators routinely flatten allOf and ignore not,
so a generated client could carry a bannedDeviceId field for a route that never
returns one — the failure mode being a client that reads the field and quietly
gets undefined, or a doc page that advertises it.

invert the composition instead of expressing the public schema by subtraction.
PublicUserBan is now a plain object holding the ten shared fields, with no allOf
and no not, so there is nothing for a generator to flatten wrongly. UserBan is
PublicUserBan plus bannedDeviceId, where flattening produces exactly the intended
superset.

no behaviour change: the han... (continued)

1145 of 1459 branches covered (78.48%)

Branch coverage included in aggregate %.

3128 of 3528 relevant lines covered (88.66%)

77.65 hits per line