行级安全（RLS）是苏帕贝斯（Supabase）最强大的功能之一，也是最受误解的功能之一。如果你曾编写过在仪表盘中运行正常但在你的 Next.js 应用中静默失败的苏帕贝斯策略，那么这篇文章就是为你准备的。
我正在构建 Wishyze，一个由人工智能驱动的自我肯定平台。我们基于 Next.js 14、苏帕贝斯（身份验证 + Postgres）运行，拥有约 28,000 名用户。行级安全是我们数据模型的支柱——每个用户的仪式、连续打卡记录和偏好都在数据库层面进行了隔离。以下是我通过艰难实践学到的一切。
为什么行级安全很重要（即使是独立开发者）
其核心理念很简单：你无需记得在每个应用程序接口（API）路由和每个查询中添加 userId 检查，只需在 Postgres 中编写策略一次，数据库就会自动强制执行访问控制。
听起来很棒。但在实践中，有三件事容易让人陷入困境：
- 新建的苏帕贝斯表默认禁用行级安全
- 除非经过身份验证，否则匿名密钥会绕过行级安全
-
服务端客户端与客户端客户端在使用
auth.uid()时表现不同
让我们解决所有这三个问题。
第一步：在每个表上启用行级安全
这是最常见的错误。你创建了一个表，编写了策略，但什么也没发生，因为行级安全从未被开启。
ALTER TABLE rituals ENABLE ROW LEVEL SECURITY;
ALTER TABLE user_preferences ENABLE ROW LEVEL SECURITY;
ALTER TABLE streak_data ENABLE ROW LEVEL SECURITY;
在苏帕贝斯仪表盘中有一个切换开关可以设置此项。请使用它。
第二步：编写真正有效的策略
以下是针对用户自有数据的典型模式：
-- 用户只能查看自己的仪式
CREATE POLICY "Users can view own rituals"
ON rituals
FOR SELECT
USING (auth.uid() = user_id);
-- 用户可以插入自己的仪式
CREATE POLICY "Users can create own rituals"
ON rituals
FOR INSERT
WITH CHECK (auth.uid() = user_id);
-- 用户可以更新自己的仪式
CREATE POLICY "Users can update own rituals"
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
