如何通过SUPABASE_ANON_KEY结合AccessToken限制RLS仅认证用户访问？

核心问题 #

你的查询返回空数据的原因是Supabase客户端未正确传递有效的认证token，导致请求仍以anon角色执行，而你的RLS策略仅允许authenticated角色访问，所以数据被过滤。

具体问题点 #

1. 你的supabaseClient函数定义接收options和token两个参数，但在component.js调用时只传了options，未传递token参数，导致函数内的Authorization header值为Bearer undefined，认证无效。
2. 手动设置Authorization header不如使用Supabase官方的auth方法可靠，可能遗漏客户端内部的auth状态同步。

修复方案 #

方案1：修正token传递逻辑（推荐使用官方auth方法）

重新封装supabaseClient，利用Supabase内置的setAuth方法设置认证token：

// utils.js
export function supabaseClient(options, token) {
  const client = createClient(
    process.env.NX_SUPABASE_URL,
    process.env.NX_SUPABASE_ANON_KEY,
    {
      ...options,
      schema: options.schema || 'public',
    }
  );

  // 如果存在有效token，设置客户端认证状态
  if (token) {
    client.auth.setAuth(token);
  }

  return client;
}

然后在组件中正确传递登录获取的access token：

// component.js
// 假设登录后从session中拿到有效access_token
const userSession = /* 登录后获取的session对象 */;
const supabase = supabaseClient(options, userSession.access_token);

// 注意select的语法：*需要加引号，同时指定count模式
const { data, count, error: errorCount } = await supabase
  .from('item')
  .select('*', { count: 'exact' });

方案2：手动修正header传递（不推荐，但可临时验证）

如果坚持手动设置header，需确保token被正确传入并生成有效header：

// utils.js
export function supabaseClient(options) {
  // 从options中提取token，假设你的options包含token字段
  const { token, ...restOptions } = options;
  
  const clientOptions = {
    ...restOptions,
    schema: restOptions.schema || 'public',
    global: {
      headers: {
        ...(restOptions?.global?.headers || {}),
        // 仅当token存在时添加Authorization header
        ...(token && { Authorization: `Bearer ${token}` }),
      },
    },
  };

  return createClient(
    process.env.NX_SUPABASE_URL,
    process.env.NX_SUPABASE_ANON_KEY,
    clientOptions
  );
}

组件调用时确保options包含token：

// component.js
const supabase = supabaseClient({ ...options, token: userSession.access_token });
const { data, count, error: errorCount } = await supabase
  .from('item')
  .select('*', { count: 'exact' });

额外验证步骤 #

1. 验证token有效性：解码你的access token，确认payload中的role字段值为authenticated。
2. 确认RLS启用状态：执行SQL语句验证表已启用RLS：

   SELECT relname, rowsecurity FROM pg_class WHERE relname = 'item';
   

   确保rowsecurity返回t（true）。
3. 策略有效性：你的现有策略逻辑正确，只要角色为authenticated即可访问，无需修改。

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