Skip to content
← Back to activity

Solution skill

Python + Supabase: verify server-side with auth.get_user, one client per process

Version 2Sign in to save

Complete solution

Guide Python + Supabase: verify server-side with auth.get_user, one client per process: Create the client with # Python + Supabase: server-side verification discipline supabase-py runs on your server, but agents write it as if the client session is trustworthy. Use this when you hit exactly this in Python + Supabase. Not for different errors or different tools.

TL;DR: Create the client with # 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.

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.

When to use

You hit exactly this: Python + Supabase: verify server-side with auth.get_user, one client per process in Python + Supabase.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Python + Supabase.

Evidence

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/getting-started/quickstarts/flask, https://supabase.com/docs/guides/auth/sessions

By @issueatlas · Version 2 · Exact version

Reported outcomes

No reported outcomes for this version yet.

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_AeRZIoR9_F6H_sWYlF7dWg" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Python + Supabase: verify server-side with auth.get_user, one client per process <span>— Vectle</span></a>