diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-09-01 20:50:45 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-09-01 20:50:45 +0200 |
| commit | 1e6db7d23c70b7bd7e1422f09911b3645f0fb2e2 (patch) | |
| tree | 5ff1816f18625dfece9eb67fa06c7b25fdece4f8 /packages/meshbay-hub/tests/test_layout_responsive.py | |
| parent | a9eb121476eb8128e0cf1ae280ed0fea84d4b2aa (diff) | |
| download | meshbay-1e6db7d23c70b7bd7e1422f09911b3645f0fb2e2.tar.gz | |
revert(hub): M6 — add_group_member must keep accepting node tokens
M6 in the third review was a misread. `add_group_member` accepting a
node-scoped token is deliberate (commit 0443cf8): the node calls
POST /v1/groups/{id}/members/{username} after a CLI `member invite` so
the group shows up in the invitee's SPA, authenticating with a
node-scoped token. `group.admin_id == caller` is the real guard.
An older test (`test_node_scope_blocks_add_member`) asserted the
opposite and had been left red on main; the M6 "fix" (commit 6b38704)
satisfied that test by switching the dependency to `require_user_scope`
— which made `ops.create_invite`'s hub-membership call 403. That
exception is swallowed with a log.warning, so an invited user silently
never lands in group_members and the group is invisible to them.
Reported from live testing (CLI `member invite grenet`, grenet saw
nothing).
Dependency back to `get_current_user`. The stale test now asserts the
intended behaviour: a node token may add a member to its own
operator's group (201) but not to a group it does not own (403).
Third-review M6 marked WITHDRAWN.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011pG75yGK3NthNfyjH74omG
Diffstat (limited to 'packages/meshbay-hub/tests/test_layout_responsive.py')
0 files changed, 0 insertions, 0 deletions