Only one test stack at a time can serve browser sign-in to the wiki farm #48

New Issue

2026-09-21T07:18:15Z

cgalo5758 commented

2026-09-21 07:18:15 +00:00

What a contributor runs into

A second test stack's TLS proxy cannot start. The proxy in front of the wiki farm binds a fixed host port rather than one allocated per stack, so the second container fails to bind it; the rest of that stack comes up fine and only browser sign-in is missing. Allocating the port per stack would not be enough either: the farm's sign-in cookies are scoped to the shared wildcard farm domain, and cookies are matched by domain, not by port (RFC 6265), so two stacks on that domain overwrite each other's session.

Why it costs

Two worktrees cannot both drive the wiki browser flow, which is the flow that exercises sign-in and the lifecycle controls. Provisioning is unaffected, because the console's farm API uses a bearer token over a per-stack port and sends no cookies. The chain sits behind a compose profile that is off by default, so the collision only bites stacks that opt in, and single-stack work never sees it.

Where

test/bootstrap-stack.sh, which would derive and export a per-stack farm domain and an allocated HTTPS port; the proxy's site address and the farm's config template under test/seed; and, in the console, the allowed-domains setting, the site scheme setting and the site URL builder, which emits no port today.

Done when

Each stack serves the farm under its own domain, two stacks with the profile enabled run browser sign-in at the same time, and the singleton note in the test documentation is removed. The proxy mints its own wildcard certificate per stack, so certificates cost nothing here.

Migrated from status/issues.md at b7a0e15

## What a contributor runs into A second test stack's TLS proxy cannot start. The proxy in front of the wiki farm binds a fixed host port rather than one allocated per stack, so the second container fails to bind it; the rest of that stack comes up fine and only browser sign-in is missing. Allocating the port per stack would not be enough either: the farm's sign-in cookies are scoped to the shared wildcard farm domain, and cookies are matched by domain, not by port (RFC 6265), so two stacks on that domain overwrite each other's session. ## Why it costs Two worktrees cannot both drive the wiki browser flow, which is the flow that exercises sign-in and the lifecycle controls. Provisioning is unaffected, because the console's farm API uses a bearer token over a per-stack port and sends no cookies. The chain sits behind a compose profile that is off by default, so the collision only bites stacks that opt in, and single-stack work never sees it. ## Where [`test/bootstrap-stack.sh`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/test/bootstrap-stack.sh), which would derive and export a per-stack farm domain and an allocated HTTPS port; the proxy's site address and the farm's config template under [`test/seed`](https://git.coopcloud.tech/wiki-cafe/member-console/src/commit/b7a0e15/test/seed); and, in the console, the allowed-domains setting, the site scheme setting and the site URL builder, which emits no port today. ## Done when Each stack serves the farm under its own domain, two stacks with the profile enabled run browser sign-in at the same time, and the singleton note in the test documentation is removed. The proxy mints its own wildcard certificate per stack, so certificates cost nothing here. Migrated from status/issues.md at b7a0e15

cgalo5758 added the

kind

debt

area/fedwiki area/testing labels 2026-09-21 07:18:15 +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#48