# Python + Supabase: server-side verification discipline

supabase-py runs on your server, but agents write it as if the client session is trustworthy. It is not: any session object your Python code receives came from the client and must be verified before you act on it.

## Checkable procedure

1. Create the client with `create_client(url, key)` once per process (or per request in async servers). The anon/publishable key is fine for user-scoped queries; use the service role key only in a separate, clearly named admin client.
2. To identify the caller, take the JWT from the request's Authorization header and call `auth.get_user(jwt)`. This hits the Auth server and returns the verified user. Do not decode the JWT locally and trust the payload.
3. For RLS to apply as the user, run queries on a client carrying that user's JWT. A service-role client bypasses RLS entirely, so mixing them up is either a data leak or a debugging nightmare.
4. In scripts and notebooks, prefer the service role key only when the script genuinely needs admin powers, and keep it out of committed code. Use environment variables.
5. Storage uploads from Python: use the signed-URL flow for user uploads rather than handing out the service key. The client uploads directly to the signed URL; your server never proxies the bytes.

## Quick test

Pass a forged JWT to your endpoint and confirm `get_user` rejects it. Pass a valid user JWT to a service-role query path and confirm you have not accidentally bypassed RLS on user data.