pg-multitenant Test Frontend

Proves RLS tenant isolation live against the real auth-api tables (auth_users, sign_in_sheets, question_user/question_sheet, sign_ins). Every request goes through app_service, the exact role the real backend connects as.

Create a new user

Users (current context)

EmailNameRoleclient_id

Create a sign-in sheet

Sheets (current context)

AddressOwnerActiveclient_id

Add a question to the library

User's question library

PromptTypeRequired

Copy to sheet

Questions on this sheet

PromptTypeRequired

Record a visitor sign-in

Select a sheet to load its questions.

Sign-ins for this sheet

NameTypeAnswers

🔒 Isolation Proof

These four scenarios demonstrate the core mechanism from the main README.md: client_id = current_client_id() OR current_app_role() = 'super_admin', enforced via FORCE ROW LEVEL SECURITY — regardless of what the frontend requests.

1. Read with no context

No client_id, no role set → fail-closed, 0 rows expected.


          

          

            
2. Set a foreign tenant

            
demo-other-tenant as context → auth-api's data stays invisible even though it exists.

            
            

          

          

            
3. super_admin bypass

            
Role super_admin, no tenant set → all rows, across tenants.

            
            

          

          

            
4. Force a cross-tenant insert

            

              Context = auth-api, but the INSERT row's client_id is
              explicitly forged to a foreign tenant → WITH CHECK must block it.