# Dyad Supabase 登录：让两名测试用户只看到自己的预约

未创建或连接 Supabase 项目，未执行双用户数据库测试。图中是测试矩阵与本地数据说明，不是 RLS 已验证的结果。

## 本地运行

需要 Node.js 20+，本参考工程没有 npm 第三方运行依赖。

```sh
npm ci --ignore-scripts
npm run check
npm run dev
```

服务只绑定 127.0.0.1:8456；修改端口可运行 `PORT=8457 npm run dev`。W03 与 W11 包含随包本地 React 18.3.1 UMD 运行库及许可，前者 hash 路由不需要服务器路径回退。

## 七步操作

### 1. 准备隔离的 Supabase 练习项目

不要复用真实客户预约库。先读本页 scope 与 fixtures.json：只有两个虚构 UUID 和两条匿名预约；本地页面只是解释每个测试应观察到什么，不执行用户登录或权限隔离。

```sh
node verify.mjs
```

### 2. 通过 Dyad 的官方连接入口授权

在应用详情选择 Connect Supabase，再核对组织和练习项目。授权成功与选择正确项目是两件事。服务端密钥不得放进浏览器源码；本题不提供真实账号、token 或连接成功截图。

### 3. 执行带主键和用户所有权的迁移

在自己的空练习库审查 schema.sql 后执行。owner_id 关联 auth.users(id)，启用 RLS；显式撤销 anon/authenticated 的既有表权限，再只给 authenticated 本题需要的读写权限。SELECT/DELETE 使用 auth.uid()=owner_id，INSERT 用 WITH CHECK，UPDATE 同时约束旧记录和新 owner_id。

```sh
cat schema.sql
```

### 4. 创建两个真实测试账号和预约

用练习账号 A、B 各登录一次，将各自真实用户 UUID 替换夹具占位值。分别通过用户会话插入一条记录。不能用 SQL 管理员或 service_role 查询代替用户会话测试，因为它们可能绕过 RLS。

### 5. 运行真实双用户权限矩阵

将 Supabase URL、publishable/anon key 与两个短期用户 access token 仅放终端环境，运行 test-rls.mjs。脚本读取自己的记录、尝试读取他人记录、尝试将自己的 owner_id 改为他人、检查匿名读取，并把每个真实状态保存。

```sh
node test-rls.mjs
```

### 6. 保留跨用户写入负例

仅检查返回 200 不够：PostgREST 对无权读取常返回空数组。脚本检查返回记录的 owner_id 和行数；越权 INSERT 与改 owner 必须得到明确的 401/403、SQLSTATE 42501 权限拒绝。跨用户更新/删除与匿名读取只接受明确权限拒绝或 200 空数组；500、无效 JWT 或其他服务错误会使测试失败，不能证明隔离。若失败应先修策略和目标项目，不要在前端加 filter 来掩盖漏洞。

### 7. 以数据库结果决定是否交付

本包 verification.json 的 status=passed 仅表示本地 SQL/夹具结构检查通过；scope 与 externalAuthorizationExecuted=false 明确说明远端权限测试尚未执行。你必须获得真实双用户矩阵通过后才可宣称隔离成立，并删除练习数据、撤销短期 token。

```sh
node verify.mjs
```

## 输入与许可

虚构业务、客户、活动及几何插图均为本站原创教学输入；参考源码采用 MIT（见 LICENSE）。不是 Dyad/bolt.diy/screenshot-to-code UI 或模型输出。不包含真实 API 密钥、账号、发布 URL 或客户资料。

官方依据：
- https://www.dyad.sh/docs/integrations/supabase

查询词仅为任务意图，不是已验证 Google 月搜索量或抖音指数。