feat(tenant): remove the single-tenant cargo feature; no normal user lands in the default tenant #187
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/pms-262-remove-single-tenant-feature"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
PMS-262 (step 7/9 of PMS-255 per-user isolation). The
single-tenantfeature was the original "everyone shares one tenant" design: it pinned every operation to the fixed UUID00000000-0000-0000-0000-000000000001viadb::tenant::default_tenant_id()andDefault for TenantContext, the single biggest cross-tenant data-leak vector. Remove the feature entirely so that shared-data code path can no longer be compiled or reached. There is deliberately noDefault for TenantContextany more: a tenant must always be resolved from an authenticated identity, never fall back to a shared constant.Drop
single-tenant = []from Cargo.toml (default features stay["multi-tenant", "server"]), delete the two#[cfg(feature = "single-tenant")]arms in main.rs (is_multi_tenantis now unconditionally true and the startup log no longer claims single-tenant mode), and refresh the staleresolve_tenant_for_logindoc that referenced the removed symbol.Default-tenant disposition is now documented as INFRA-ONLY: the only legitimate residents of
Uuid::from_u128(1)(the Bunyip default landing tenant,OIDC_DEFAULT_TENANT_ID) are platform super_admins.place_bunyip_useralready backfills every non-admin out of it into a personal tenant on next login (is_stuck_in_default, PMS-245); this pins that contract with two end-to-end placement tests in tests/bunyip_login.rs - a non-admin parked in the default tenant is rehomed into their own personal tenant, and a super_admin is left in place. Documented in db/tenant.rs and dev-docs/codebase-state.md.#PMS-262