Supabase RLS基于user_metadata的company_id过滤产品异常排查

针对你遇到的RLS规则不生效、但前端直接过滤正常的问题，以下是核心排查方向和解决方法：

1. JWT令牌未及时更新 #

调用updateUser修改user_metadata后，当前会话的JWT令牌不会自动更新——后端验证RLS时依赖的是请求头中的JWT，而旧JWT里的user_metadata还是修改前的值，这是最常见的原因。

解决方法：

• 修改用户元数据后，立即刷新会话以获取新的JWT：

  const { data: authData, error: authErr } = await supabase.auth.updateUser({ 
    data: { company_id, role: 'manager' } 
  });
  // 刷新会话，更新JWT
  if (!authErr) {
    const { data: refreshedSession } = await supabase.auth.refreshSession();
    // 可选：更新本地存储的会话（比如SvelteKit的session store）
  }
  

• 或者让用户重新登录，确保新会话携带更新后的user_metadata。

2. RLS规则的数据类型转换错误 #

你尝试过转换类型但无效，可能是转换方向搞反了：

• 如果product表的company_id是bigint类型，应该把JWT中字符串格式的company_id转成bigint，而非反过来：

  -- 正确的RLS规则（针对bigint类型的company_id）
  (auth.jwt() -> 'user_metadata' ->> 'company_id')::bigint = company_id
  

• 先确认product表中company_id的实际数据类型（比如是int还是bigint），再匹配对应的转换方式。

3. RLS规则的角色绑定错误 #

确保你的RLS规则是绑定到authenticated角色上的：

• 进入Supabase控制台 → 对应表 → "权限"标签页
• 确认authenticated角色的SELECT权限已开启，且你的RLS规则是添加在该角色的权限配置下
• 如果规则绑定到了其他角色（比如anon），而你的用户是authenticated身份，规则自然不会生效。

4. 直接在SQL编辑器验证RLS规则 #

排除前端干扰，直接在Supabase SQL编辑器中测试规则是否有效：

-- 切换到authenticated角色
set role authenticated;
-- 模拟带指定company_id的JWT
set jwt.claims '{"user_metadata": {"company_id": "10"}}';
-- 查询产品，验证是否只返回company_id=10的记录
select * from product;

如果这里查询结果正确，说明规则本身没问题，问题出在前端的会话或请求上；如果结果不对，说明规则本身需要调整。

5. 前端会话同步问题 #

确保前端发起查询时，使用的是更新后的会话：

• 在SvelteKit中，如果你使用了supabaseAuthHelper或自定义的session store，需要确保updateUser后及时更新store中的会话数据
• 避免使用缓存的旧会话发起请求，导致JWT未更新。

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