Debug Rls

debug-rls

Systematic methodology for debugging Row-Level Security issues in Butterbase. Uses role simulation (as_role/as_user parameters) to verify policy behavior without needing real user sessions.

1. Overview

Row-Level Security (RLS) in Butterbase controls which rows each database role can see or modify. When RLS is misconfigured, users may see no data, too much data, or get unexpected errors on insert. This skill walks through a repeatable four-step process to identify and fix the root cause.

Key principle: MCP tools default to the service key (bb_sk_...), which bypasses all RLS. Always use as_role/as_user to simulate the role your frontend actually uses.

2. Quick Diagnosis

Match the symptom your user reports to the most likely cause before diving into the full protocol.

3. The Three Roles

Butterbase automatically assigns a database role based on the auth header of each request. You never create these roles — they are built in.

Important: When you call select_rows or insert_row without as_role, you are always running as butterbase_service. This means the result tells you nothing about what a real user would see. Use as_role to simulate the correct role.

4. Four-Step Debugging Protocol

Work through these steps in order. Each step narrows down the cause.

Step 1: Check if RLS is enabled

Call manage_rls with action: "list" for the app_id:

manage_rls(app_id: "app_abc123", action: "list")

Returns { policies: [...], tables_with_rls: [...] }. The tables_with_rls array shows which tables have RLS turned on but no policies yet (effective default deny).

• Look for the table in the response.
• If the table has no policies, RLS might not be enabled at all — or it was enabled but no policies were added, which causes a default deny for all non-service roles.
• If the table does appear, move to Step 2 to inspect what the policies actually do.

A table with RLS enabled but zero policies is inaccessible to butterbase_anon and butterbase_user. The butterbase_service role is unaffected.

Step 2: Inspect existing policies

Read each policy's fields carefully:

Common issues to look for:

• Policy exists for butterbase_user but not butterbase_anon (anonymous users blocked)
• Policy exists for SELECT but not INSERT (reads work, writes fail)
• USING expression references the wrong column (e.g., owner_id instead of user_id)
• Policy covers ALL commands but the WITH CHECK expression is missing (inserts may fail silently)

Step 3: Test as different roles

Use the as_role and as_user parameters on select_rows and insert_row to simulate each role. This is the most direct way to reproduce what a real user experiences.

# Test SELECT as an authenticated user
select_rows(
  app_id: "app_abc123",
  table: "posts",
  as_role: "user",
  as_user: "user-uuid-here"
)

# Test SELECT as anonymous
select_rows(
  app_id: "app_abc123",
  table: "posts",
  as_role: "anon"
)

# Test INSERT as an authenticated user
insert_row(
  app_id: "app_abc123",
  table: "posts",
  data: { title: "Hello" },
  as_role: "user",
  as_user: "user-uuid-here"
)

Compare results between roles:

If results differ from expectations, you have confirmed which role/command combination is misconfigured.

Without as_role, MCP tools always use the service key and bypass RLS. Never use this to validate that RLS is working.

Step 4: Check auto-populate trigger

This step specifically diagnoses AUTH_RLS_POLICY_VIOLATION on INSERT.

1. Insert a row as a user (using as_role: "user"):

insert_row(
  app_id: "app_abc123",
  table: "posts",
  data: { title: "Test post" },
  as_role: "user",
  as_user: "user-uuid-here"
)

2. Check if the user_id / author_id column was auto-populated in the returned row.

3. If the column is NULL or missing from the response, the auto-populate trigger is missing. The RLS policy requires user_id = current_user_id(), but the column was never filled in, so the WITH CHECK fails.

Root cause: enable_rls + create_policy (without user_column) does not install an auto-populate trigger. Clients would need to manually include the user column in every POST body — which most frontends don't do.

Fix: See Fix 1 or Fix 3 in the next section.

5. Common Fixes

Four ready-to-use recipes. Copy the MCP tool call that matches your situation.

Fix 1: Enable basic user isolation

Use this when a table has no RLS at all and you want users to only see their own rows.

manage_rls(
  app_id: "app_abc123",
  action: "create_user_isolation",
  table_name: "posts",
  user_column: "author_id"
)

What this creates automatically:

• RLS enabled on the table
• User isolation policy: author_id = current_user_id()::uuid for ALL commands
• Auto-populate trigger: sets author_id from the JWT on INSERT (clients don't need to send it)
• Service bypass: butterbase_service always passes through (built into the platform)

This is the recommended starting point for any user-owned data table.

Fix 2: Add public read access

Use this when you want anonymous users (or all authenticated users) to be able to read certain rows — for example, published blog posts or public profiles.

manage_rls(
  app_id: "app_abc123",
  action: "create_policy",
  table_name: "posts",
  policy_name: "public_read_published",
  command: "SELECT",
  role: "anon",
  using_expression: "published = true"
)

This lets anonymous users read posts where published = true. They still cannot read unpublished posts or write anything.

To also allow authenticated (non-anonymous) users to read public rows, add a second policy with role: "user" and the same using_expression.

Alternatively, if you haven't set up user isolation yet, use the public_read_column shorthand:

manage_rls(
  app_id: "app_abc123",
  action: "create_user_isolation",
  table_name: "posts",
  user_column: "author_id",
  public_read_column: "published"
)

This sets up user isolation and adds permissive SELECT policies for both butterbase_user and butterbase_anon to read rows where published = true — in a single call.