如何在Supabase RLS中使用IN与SELECT，无需开放关联表无限制权限

你遇到的问题核心是：RLS策略中的子查询会触发关联表（比如projects）的RLS规则，当前用户无访问该表的权限时，子查询返回空，最终导致主表策略验证失败。以下是几种无需开放关联表全部权限的解决方案：

方法一：使用SECURITY DEFINER函数封装跨表逻辑 #

通过创建带SECURITY DEFINER属性的函数，让函数以高权限定义者（如supabase_admin）身份执行跨表查询，绕过关联表的RLS限制，同时严格控制函数的执行权限与内部逻辑，避免数据泄露。

操作步骤： #

1. 创建封装查询的函数：

-- 替换uuid为你project_id的实际数据类型
CREATE OR REPLACE FUNCTION get_allowed_project_ids()
RETURNS SETOF uuid
LANGUAGE plpgsql
SECURITY DEFINER
AS $$
BEGIN
  -- 可添加精准过滤逻辑，比如仅返回当前用户有权访问的项目ID
  RETURN QUERY SELECT id FROM projects;
END;
$$;

-- 给需要执行该函数的角色（如authenticated）授予执行权限
GRANT EXECUTE ON FUNCTION get_allowed_project_ids() TO authenticated;

2. 修改主表的RLS策略：

CREATE POLICY "允许访问关联项目的记录" ON your_target_table
FOR SELECT USING (project_id IN (SELECT get_allowed_project_ids()));

注意：SECURITY DEFINER函数权限极高，必须在内部添加严格过滤逻辑（比如关联auth.uid()限制返回当前用户的项目），禁止返回全表数据；避免给anon角色授予函数执行权限，除非确有必要。

方法二：给关联表添加针对性RLS策略 #

若跨表逻辑基于用户身份，可给projects表添加仅允许特定场景访问的RLS策略，而非开放全部权限。例如：

CREATE POLICY "允许其他表RLS策略查询项目ID" ON projects
FOR SELECT USING (true) -- 可根据需求添加更严格条件，比如关联当前用户
TO authenticated; -- 仅允许认证用户通过该策略查询

这种方式适用于跨表逻辑简单、可通过角色/用户身份明确过滤的场景，比SECURITY DEFINER更轻量，但需确保projects表的策略不会泄露敏感数据。

方法三：角色分层隔离权限 #

创建专门角色并授予关联表访问权限，再让需要执行跨表RLS策略的用户角色继承该权限：

-- 创建专门角色
CREATE ROLE project_viewer;
-- 授予该角色projects表的SELECT权限
GRANT SELECT ON projects TO project_viewer;
-- 让authenticated角色继承该权限
GRANT project_viewer TO authenticated;

此方法适合多表需共享关联表权限的场景，需遵循权限最小化原则，不授予不必要的操作权限（如INSERT/UPDATE）。

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