D2 — Tenant identification: Request Data (per user instruction)
Architecture decision record, relocated verbatim from the retired single-file
docs/tenancy/decision log. Status, thematic clusters, and how to record a new ADR: the decision log index.
Use Stancl\Tenancy\Middleware\InitializeTenancyByRequestData.
- Primary:
X-TenantHTTP header (API / SPA / service-to-service). - Fallback: query parameter (e.g.
?tenant=) for non-browser / link-based flows. - Browser/Livewire: a tenant cookie set server-side.
- No domain/subdomain identification.
Security model (critical): request-data identification only selects a context; it does not authorize. The header/cookie is attacker-controllable, so:
- RLS at the DB enforces row isolation regardless of what is requested.
- A tenant-membership guard runs after authentication and rejects the request (403) unless the authenticated user belongs to the identified tenant. The tenant a user may act in is derived from the user, never trusted blindly from the header.
- The central (backoffice) surface is a separate route group with its own auth and never initializes tenancy from request data.