RLS Verification Runbook

This document describes how to verify Row Level Security (RLS) behavior in BacMR.

Prerequisites

• Postman installed and configured with the BacMR collection.
• Access to Supabase Dashboard (to create/manage test users).

Test Scenario 1: User Profile Isolation

Goal: Verify that a student can only see their own profile.

1. Sign in as Student A (student-a@example.com).
2. Copy the JWT from the login response.
3. Execute GET /me.
4. Expected Result: 200 OK. Data matches Student A's ID.
5. Try to access Student B's data (if you have their UUID).
6. Note: Our API currently only has /me which uses the JWT subject, so cross-user access via API is blocked by design. Direct DB queries via Supabase REST API would be blocked by RLS.

Test Scenario 2: Admin Role Check

Goal: Verify that only admins can access /admin endpoints.

1. Sign in as Student A.
2. Execute GET /admin/test-role.
3. Expected Result: 403 Forbidden.
4. Sign in as Admin User (admin@bacmr.com).
5. Execute GET /admin/test-role.
6. Expected Result: 200 OK. Response shows is_admin: true and method: jwt.

Test Scenario 3: Fallback Admin Key

Goal: Verify that X-Admin-Key still works for system tasks.

1. Send request to GET /admin/test-role without a Bearer token.
2. Add Header: x-admin-key: <your_secret_key>.
3. Execute.
4. Expected Result: 200 OK. Response shows method: x-admin-key.

Test Scenario 4: Wallet Isolation

Goal: Verify that a student cannot see another student's wallet ledger.

1. Sign in as Student A.
2. Execute GET /wallet/ledger.
3. Expected Result: Only shows transactions belonging to Student A.
4. Sign in as Student B.
5. Expected Result: Only shows transactions belonging to Student B.

Troubleshooting

• If Student A sees Student B's data: RLS is likely disabled or the policy is too broad. Check db/migrations/...rls_phase_1.sql.
• If Admin is blocked: Ensure the user metadata in Supabase Auth contains {"role": "admin"}.