P0 hosted: per-user session issuance replaces the single shared local-user token #71

New issue

Open

opened 2026-09-06 18:31:54 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-06 18:31:54 +00:00

Owner

Problem

quasar.app:start registers exactly ONE websocket session (principal local-user, workspace default) and injects that single token into every served page via quasar.ui:inject-session-token. The desktop security model is single-user; on a hosted deployment every visitor would share the same principal and full write authority to the shared workspace.

The enforcement layer is already multi-principal (register-websocket-session carries principal / authority-kind / workspaces / capabilities; every command is workspace-gated with security.forbidden; unknown tokens are rejected 401 at handshake). The gap is issuance only.

Required

A way to suppress the default shared local-user session for hosted deployments (flag or init config), and an API to unregister/expire a registered session token (only register-websocket-session exists today).
Per-request session-token injection: the CLOG boot path must be able to resolve a principal per browser request (e.g. cookie or authorization header) instead of closing over one global token, so a plugin can mint per-user tokens.
quasar.app:start should expose allowed-origins and capabilities of make-websocket-server (currently hard-wired to localhost dev origins, so a production origin is denied even with a valid token).

Non-goals

Quasar core does not pick an identity provider; per #58 the authn policy itself belongs to trusted init plugins (starintel-biz implements the interim CouchDB one, StarIntel OIDC later per #56).

Acceptance

Hosted start can run with no shared token issued and no unauthorized visitor able to reach a workspace.
A trusted init plugin can register/unregister per-principal sessions and influence the injected token per request.
Origin allowlist configurable for a public origin.

## Problem `quasar.app:start` registers exactly ONE websocket session (principal `local-user`, workspace `default`) and injects that single token into every served page via `quasar.ui:inject-session-token`. The desktop security model is single-user; on a hosted deployment every visitor would share the same principal and full write authority to the shared workspace. The enforcement layer is already multi-principal (`register-websocket-session` carries principal / authority-kind / workspaces / capabilities; every command is workspace-gated with `security.forbidden`; unknown tokens are rejected 401 at handshake). The gap is issuance only. ## Required - A way to suppress the default shared `local-user` session for hosted deployments (flag or init config), and an API to unregister/expire a registered session token (only `register-websocket-session` exists today). - Per-request session-token injection: the CLOG boot path must be able to resolve a principal per browser request (e.g. cookie or authorization header) instead of closing over one global token, so a plugin can mint per-user tokens. - `quasar.app:start` should expose `allowed-origins` and `capabilities` of `make-websocket-server` (currently hard-wired to localhost dev origins, so a production origin is denied even with a valid token). ## Non-goals - Quasar core does not pick an identity provider; per #58 the authn policy itself belongs to trusted init plugins (starintel-biz implements the interim CouchDB one, StarIntel OIDC later per #56). ## Acceptance - Hosted start can run with no shared token issued and no unauthorized visitor able to reach a workspace. - A trusted init plugin can register/unregister per-principal sessions and influence the injected token per request. - Origin allowlist configurable for a public origin.

nsaspy referenced this issue

2026-09-06 18:32:15 +00:00

P0 init: minimum trusted-plugin hook surface for hosted auth (slice of #58) #73

nsaspy referenced this issue from starintel-labs/starintel-biz

2026-09-06 19:08:26 +00:00

Track interim Quasar hosted authentication plugin #7