Skip to content

console: workspace members page offers Invite / Remove member to the member role; only the server 403 stops it #8092

Description

@baozhoutao

On /_console/organizations/<slug>/members, a user whose org role is member is shown the Invite member button and a per-row Member actions menu containing Remove member — including on the row of the workspace Owner. Nothing is disabled or hidden; the action only fails after the user commits to it.

Repro

  1. User A owns workspace 甲; user B joins it as member.
  2. As B, open /_console/organizations/acme-jia/members.

Actual

  • Invite member (top right) is enabled. Opening it, filling an email and pressing Send invitation fails inline with the raw English server message You are not allowed to invite users to this organization (also see the i18n issue).
  • The … menu on every row, the Owner's included, offers Remove member.

The server does gate the write — POST /api/v1/auth/organization/invite-member as the member returns:

403 {"message":"You are not allowed to invite users to this organization",
     "code":"YOU_ARE_NOT_ALLOWED_TO_INVITE_USERS_TO_THIS_ORGANIZATION"}

so this is a UI-gating gap, not a privilege escalation. (remove-member was not exercised destructively; a probe with a non-existent member returned 400 MEMBER_NOT_FOUND, i.e. the lookup runs before the permission check, so that path's gating is unverified from the client side and worth a look while fixing.)

Expected

A member sees no invite or remove affordances — matching the Settings tab of the very same page, which already gets this right: it replaces the form with "只有所有者可以修改设置。" and disables Delete organization while leaving Leave organization enabled. The members/invitations tabs simply never got the same treatment.

Where

packages/app-shell/src/console/organizations/manage/ — MembersPage (invite button + row actions) and InviteMemberDialog. The active member's role is already available via the org context used elsewhere on the page.

Environment

Local dev server http://localhost:8080, multi-org enabled, zh locale, observed 2026-08-12. The server was started by the maintainer and its exact commit is not verified.

Activity

  1. baozhoutao commented on Aug 12, 2026

    @baozhoutao
    ContributorAuthor

    Found in the same multi-org walkthrough (sign-up → create workspace → invite → second user accepts → second workspace → switch → isolation/authz probes): #8090, #8091, #8092, #8093, #8094.

  2. baozhoutao commented on Aug 12, 2026

    @baozhoutao
    ContributorAuthor

    Two further findings from the same pass, filed for the platform to rule on: #8095, #8096.

  3. hotlong commented on Aug 12, 2026

    @hotlong
    Contributor

    Moved to objectstack-ai/objectui#4475 (rebuilt verbatim + provenance header; native transfer is not available to this seat). Closing here as moved — authority: the repo-routing rule "Issue 住在修复落地的仓" (maintainer ruling 2026-08-10, recorded in the pm-dispatch skill); the fix is UI affordance gating in objectui's MembersPage / InviteMemberDialog. The filer-applied domain:access-security label is not a lane in the domain table and does not travel (standing triage rule ⑤). The server-side half this walkthrough surfaced — whether org_member should read the invitation ledger at all — stays in objectstack as #8095 (needs-user-decision). 本评论来自分诊座位 Routine。


    Generated by Claude Code

  4. baozhoutao commented on Aug 13, 2026

    @baozhoutao
    ContributorAuthor

    Follow-up: the server-side refusal a member hits from this UI is itself mislabelled — see the remove-member error-mapping issue filed alongside this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions