From e3fbb234c0ad615980fb3bd4e05cb4c68b3d5220 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 31 Aug 2026 05:29:40 +0000 Subject: [PATCH] docs(skills): sever the X-Tenant-ID cause-and-effect in the auth guide The "Multi-tenancy" section taught that createAuthenticatedFetch sending X-Tenant-ID is what makes row-level isolation happen. It is not: scoping comes from the session, the header is an edge routing hint ranked behind subdomain, and trusting it as identity is the recorded plugin-sharing vulnerability. Repoint to packages/auth/README.md's "The X-Tenant-ID edge contract" (added by #5279 / PR #5706) for the full contract. --- skills/objectui/guides/auth-permissions.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/skills/objectui/guides/auth-permissions.md b/skills/objectui/guides/auth-permissions.md index 34e8754a28..d1b0588fd5 100644 --- a/skills/objectui/guides/auth-permissions.md +++ b/skills/objectui/guides/auth-permissions.md @@ -313,10 +313,12 @@ trap applies to `visible`, `disabled` and any other expression-valued key. ## Multi-tenancy -There is no client-side tenancy layer. Tenant scoping is server-enforced: -`createAuthenticatedFetch` (`@object-ui/auth`) injects the active -organization as the `X-Tenant-ID` header on every API call, and the backend -applies row-level isolation. Per-tenant branding is a `ThemeSchema` concern +There is no client-side tenancy layer. Tenant scoping is server-enforced +from the session, not from a header: `createAuthenticatedFetch` +(`@object-ui/auth`) does stamp the active organization as `X-Tenant-ID` on +requests, but that header is an edge routing hint, not identity — see +`packages/auth/README.md`, "The `X-Tenant-ID` edge contract", for what it may +and may not be trusted for. Per-tenant branding is a `ThemeSchema` concern (see the theming guide), not an auth concern. ## Provider composition pattern