排查NextJS+Auth0+Supabase架构下RLS策略失效问题

核心问题根源 #

你的userPreferences表存储的是Auth0的用户ID（格式如auth0|634e0cdd46ec7824xxxxxxxx）作为user_id，但RLS策略中使用的user_id()函数返回的是Supabase内部用户的UUID，两者完全不匹配，这就导致了UPDATE环节的RLS校验失败。虽然你提到其他INSERT操作正常，大概率是INSERT策略的实际配置与你描述的不一致，或者存在临时绕过的情况。

具体解决步骤 #

1. 修正RLS策略，匹配Auth0用户ID

将UPDATE和INSERT策略中的user_id() = user_id替换为从JWT中提取的Auth0sub值，这样才能正确对应你存储的用户ID：

-- 更新UPDATE策略
ALTER POLICY "允许用户更新自己的偏好" ON "public"."userPreferences"
USING (auth.jwt() ->> 'sub' = user_id)
WITH CHECK (auth.jwt() ->> 'sub' = user_id);

-- 同步修正INSERT策略（如果之前的策略也用了错误的规则）
ALTER POLICY "允许用户插入自己的偏好" ON "public"."userPreferences"
WITH CHECK (auth.jwt() ->> 'sub' = user_id);

2. 验证Supabase客户端的Token传递

检查getSupabase函数是否正确将Auth0的accessToken以Bearer身份传递给Supabase，确保Supabase能解析出JWT中的sub声明：

// utils/supabase.js
import { createClient } from '@supabase/supabase-js';

export const getSupabase = (accessToken) => {
  const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL;
  const supabaseAnonKey = process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY;
  return createClient(supabaseUrl, supabaseAnonKey, {
    global: {
      headers: {
        Authorization: `Bearer ${accessToken}`,
      },
    },
  });
};

3. 调试RLS策略的实际值

如果问题仍存在，可以临时给RLS策略添加调试逻辑，查看实际的JWTsub和数据库中user_id的值：

ALTER POLICY "允许用户更新自己的偏好" ON "public"."userPreferences"
USING (
  auth.jwt() ->> 'sub' = user_id
  OR (
    pg_notify('rls_debug', 'JWT sub: ' || auth.jwt() ->> 'sub' || ', 行user_id: ' || user_id)
    AND false
  )
);

然后在Supabase的SQL编辑器中执行以下语句监听调试信息：

LISTEN rls_debug;

执行upsert操作后，查看控制台输出的实际值，确认两者是否匹配。

4. 确认upsert逻辑的正确性

在API路由中添加日志，确认传递的user_id确实是当前用户的Auth0sub：

console.log('当前用户sub:', user.sub);

同时检查数据库中已存在的userPreferences记录的user_id是否与当前用户的sub完全一致。

内容的提问来源于stack exchange，提问作者gorlaz