Supabase RLS使用IN子句的策略始终失效问题排查

核心原因：请求发起者无projects表的RLS访问权限 #

你猜的没错——当RLS策略中的子查询SELECT projects.id FROM projects执行时，会以当前请求的用户身份去访问projects表。如果这个用户没有被授权查询projects表（比如projects表没开RLS，或者RLS策略不允许该用户访问），子查询会返回空结果，导致你的目标表策略完全失效。而固定值project_id = 8不需要访问其他表，所以能正常生效。

验证方法 #

可以临时给projects表添加一个全量读取的RLS策略测试：

CREATE POLICY "Temp allow all projects read" ON projects
FOR SELECT USING (true);

如果此时你的目标表策略（用子查询的那个）开始生效，就坐实了是projects表的权限问题。测试完记得删除这个临时策略，避免安全风险：

DROP POLICY "Temp allow all projects read" ON projects;

合理的解决方案（无需开放全表权限） #

方案1：用安全定义器（SECURITY DEFINER）函数封装子查询 #

创建一个以超级用户权限执行的函数，返回用户有权访问的项目ID列表。这样无需给普通用户开放projects表的权限，函数执行时会用创建者的身份访问projects表。

1. 创建函数（根据你的业务逻辑调整查询条件）：

CREATE OR REPLACE FUNCTION get_user_allowed_projects()
RETURNS SETOF INTEGER
LANGUAGE plpgsql
SECURITY DEFINER
AS $$
BEGIN
  -- 示例1：返回所有项目（根据实际需求修改，比如关联用户-项目权限表）
  RETURN QUERY SELECT id FROM projects;
  
  -- 示例2：返回当前用户有权访问的项目（假设存在user_projects关联表）
  -- RETURN QUERY 
  --   SELECT p.id 
  --   FROM projects p 
  --   JOIN user_projects up ON p.id = up.project_id 
  --   WHERE up.user_id = auth.uid();
END;
$$;

-- 授权普通认证用户可以调用该函数
GRANT EXECUTE ON FUNCTION get_user_allowed_projects() TO authenticated;

2. 修改目标表的RLS策略：

CREATE POLICY "Allow access to authorized projects" ON your_target_table
FOR SELECT USING (project_id IN (SELECT get_user_allowed_projects()));

方案2：给projects表添加最小权限的RLS策略 #

如果不想用安全定义器函数，可以给projects表添加一个精准的RLS策略，只允许用户访问他们有权查看的项目，而不是开放全表权限。

比如，假设用户通过user_projects表关联到项目：

CREATE POLICY "Allow read access to user's projects" ON projects
FOR SELECT USING (
  EXISTS (
    SELECT 1 
    FROM user_projects up 
    WHERE up.project_id = projects.id 
    AND up.user_id = auth.uid()
  )
);

这样用户只能查询自己关联的项目，子查询就能正确返回结果，同时保证projects表的安全性。

其他可能的小问题 #

• 检查projects表的拼写是否正确（Supabase默认使用小写表名，注意大小写匹配）
• 确认projects表是否启用了RLS（如果没启用，默认只有超级用户能访问，普通用户查不到）

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