Supabase

Auth

// Sign up
const { data, error } = await supabase.auth.signUp({ email, password });

// Sign in
const { data, error } = await supabase.auth.signInWithPassword({ email, password });

// OAuth
const { data, error } = await supabase.auth.signInWithOAuth({ provider: 'google', options: { redirectTo: `${origin}/auth/callback` } });

// Get current user
const { data: { user } } = await supabase.auth.getUser();

// Sign out
await supabase.auth.signOut();

// Auth state listener
supabase.auth.onAuthStateChange((event, session) => { /* handle */ });

Row Level Security (RLS)

RLS is non-negotiable with Supabase. Every table exposed to the client MUST have policies:

-- Enable RLS
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

-- Users see only their own orders
CREATE POLICY "Users see own orders" ON orders
  FOR SELECT USING (auth.uid() = customer_id);

-- Users can insert their own orders
CREATE POLICY "Users create own orders" ON orders
  FOR INSERT WITH CHECK (auth.uid() = customer_id);

-- Users can update their own orders
CREATE POLICY "Users update own orders" ON orders
  FOR UPDATE USING (auth.uid() = customer_id);

-- Admins see everything
CREATE POLICY "Admins see all" ON orders
  FOR ALL USING (
    EXISTS (SELECT 1 FROM profiles WHERE id = auth.uid() AND role = 'admin')
  );

Rules:

• Enable RLS on EVERY table that the client JS accesses
• Use auth.uid() to scope queries to the authenticated user
• Test policies with different user roles
• Tables without RLS and with the anon key exposed = full public access (security breach)

Storage

// Upload
const { data, error } = await supabase.storage.from('avatars').upload(`${userId}/avatar.jpg`, file, {
  contentType: 'image/jpeg',
  upsert: true,
});

// Get public URL
const { data: { publicUrl } } = supabase.storage.from('avatars').getPublicUrl(`${userId}/avatar.jpg`);

// Download
const { data, error } = await supabase.storage.from('documents').download(`${path}`);

Set storage bucket policies in the dashboard — same RLS concepts apply to storage.

Realtime

// Subscribe to changes
const channel = supabase.channel('orders').on(
  'postgres_changes',
  { event: 'INSERT', schema: 'public', table: 'orders', filter: `customer_id=eq.${userId}` },
  (payload) => { /* handle new order */ },
).subscribe();

// Cleanup
channel.unsubscribe();

Edge Functions

// supabase/functions/process-payment/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2';

Deno.serve(async (req) => {
  const supabase = createClient(Deno.env.get('SUPABASE_URL')!, Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!);
  const { orderId } = await req.json();
  // ... process payment with service role (bypasses RLS)
  return new Response(JSON.stringify({ success: true }), { headers: { 'Content-Type': 'application/json' } });
});

Common Pitfalls

• Missing RLS policies — tables without RLS are publicly accessible via the anon key. This is the #1 security issue.
• Using anon key for admin operations — use service role key ONLY in server-side code (Edge Functions, API routes). Never expose it to the client.
• Not generating types — untyped Supabase queries lose all type safety. Run gen types after schema changes.
• Ignoring errors — every Supabase call returns { data, error }. Always check error.
• Realtime without cleanup — forgetting unsubscribe() causes memory leaks and duplicate handlers.
• Storage without policies — storage buckets default to no access. Configure policies in dashboard.

Context7

• Supabase: search for supabase — client, auth, RLS, storage, realtime, edge functions