The create-workspace route answers any signed-in member while its control is hidden #241

New Issue

2026-10-18T19:40:01Z

cgalo5758 commented

2026-10-18 19:40:01 +00:00

What happens

A workspace is a member's working context inside an organization. Whether a member may create one has not been decided (#139), so the dashboard hides the "Create workspace" control: it shows the workspace section only when the organization already has more than one workspace, and that control is the only way to make a second one.

Hiding the control is the only gate. The routes behind it, GET /partials/workspaces/create-form and POST /partials/workspaces, are mounted for every signed-in member, and CreateWorkspace checks only that the person is signed in. A member who sends the request directly creates a workspace in their own organization. Cross-origin requests are refused, so another site cannot send it on their behalf.

What should happen

Until #139 decides who may create a workspace, the create form and the create refuse every member. Listing and switching between an organization's existing workspaces keep working. When #139 is decided, the server enforces that rule in the handler, not only in the page.

Where

internal/server/workspace_partials.go:59-64 (routes) and :101 (CreateWorkspace), internal/server/server.go:565 (mounting), :779 and :862-871 (multipleWorkspaces), internal/embeds/templates/index.html:104

Why it matters

A feature nobody has decided on is reachable by anyone who signs in. A new workspace attaches to the organization's existing pool and limits are counted per pool, so it multiplies no limit today, but each later rule #139 settles would start from an open door.

Related: #139 holds the policy question; #240 covers the default pool this handler can create.

### What happens A workspace is a member's working context inside an organization. Whether a member may create one has not been decided (#139), so the dashboard hides the "Create workspace" control: it shows the workspace section only when the organization already has more than one workspace, and that control is the only way to make a second one. Hiding the control is the only gate. The routes behind it, `GET /partials/workspaces/create-form` and `POST /partials/workspaces`, are mounted for every signed-in member, and `CreateWorkspace` checks only that the person is signed in. A member who sends the request directly creates a workspace in their own organization. Cross-origin requests are refused, so another site cannot send it on their behalf. ### What should happen Until #139 decides who may create a workspace, the create form and the create refuse every member. Listing and switching between an organization's existing workspaces keep working. When #139 is decided, the server enforces that rule in the handler, not only in the page. ### Where `internal/server/workspace_partials.go:59-64` (routes) and `:101` (`CreateWorkspace`), `internal/server/server.go:565` (mounting), `:779` and `:862-871` (`multipleWorkspaces`), `internal/embeds/templates/index.html:104` ### Why it matters A feature nobody has decided on is reachable by anyone who signs in. A new workspace attaches to the organization's existing pool and limits are counted per pool, so it multiplies no limit today, but each later rule #139 settles would start from an open door. Related: #139 holds the policy question; #240 covers the default pool this handler can create.

cgalo5758 added the

kind

bug

area/identity area/member-ui security labels 2026-10-18 19:40:01 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#241