decentraland / social-service-ea / 35004170927

91%

main: 91%

push

github

fix: stop returning private communities to unauthenticated callers (#488)

* fix: stop returning private communities to unauthenticated callers

getCommunityPublicInformation passes onlyPublic: true to the members-count CTE,
where it becomes `AND c.private = false` inside that CTE. The CTE only computes
counts and is LEFT JOINed, so the predicate filters nothing; the outer query is
just `WHERE c.id = $1 AND c.active = true`.

get-community-handler routes an unauthenticated request to this function, so
GET /v1/communities/<private id> answered 200 with the id, name, description,
owner address, Catalyst-resolved owner name and privacy: "private". The unmatched
join yields NULL for the count, so it read as a community with no members rather
than as anything unusual. /v2 shares the adapter method and behaved the same.

The predicate now sits in the query's own WHERE, so both versions return 404.

Only `private` is excluded. Unlisted communities stay reachable by id, which is
what unlisted means: hidden from discovery, not from someone holding the link.

The sibling list query puts the same predicate in its outer WHERE, which is what
made this a transcription slip rather than a decision.

* fix: gate the authenticated by-id read on private communities too

The first commit closed the unsigned path. A signed request takes a different
branch — getCommunity(id, { as }) — whose query filters only id and active and
uses the members join solely to compute role, so any wallet holding a private
community's id still received its name, description, owner, privacy, counts and
voice status with role: none.

Refusing only the anonymous half would have been worse than not fixing it, since
the register would have shown the finding closed.

Both versions now answer 404 unless the caller may see the community. The posts
and places reads already gate on `privacy === Private && role === None`, so this
follows the pattern rather than inventing one.

A pending invite counts as... (continued)

2599 of 2999 branches covered (86.66%)

Branch coverage included in aggregate %.

9 of 10 new or added lines in 1 file covered. (90.0%)

6249 of 6702 relevant lines covered (93.24%)

93.36 hits per line