38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
# 本地 private table SQL 权限修复
|
||
|
||
场景：
|
||
- 后台或 api-server 通过 SpacetimeDB HTTP SQL 读取 `tracking_event` 这类 private table。
|
||
- 本地清库、重建 standalone 或重新发布模块后，原 CLI token 失效，SQL 可能报 `no such table ... If the table exists, it may be marked private`。
|
||
|
||
操作步骤：
|
||
|
||
1. 清空本地 SpacetimeDB 数据目录
|
||
- 使用项目脚本停止本地实例后，备份或删除 `server-rs/.spacetimedb/local/data`。
|
||
- 只清本地开发环境，不要误伤远端或其他 worktree。
|
||
|
||
2. 启动本地 standalone
|
||
- 用项目约定的 `scripts/dev-rust-stack.sh` 或等价命令启动 `spacetime`。
|
||
- 确认 `/v1/ping` 可访问后再取 identity。
|
||
|
||
3. 通过 `/v1/identity` 获取新 token 和 identity
|
||
- 使用 `POST http://127.0.0.1:3101/v1/identity`
|
||
- 只记录 identity，不要在日志中打印 token 明文。
|
||
|
||
4. 用新 token 登录 CLI
|
||
- 运行：`spacetime login --token <token>`
|
||
- 这会把 token 写到本地 CLI 配置，后续 HTTP SQL 可读 private table。
|
||
|
||
5. 重新验证 SQL
|
||
- 使用带 token 的 `POST /v1/database/<db>/sql`
|
||
- 先尝试 `SELECT ... FROM tracking_event LIMIT 1`
|
||
- 若成功，再让 api-server 走同样 token。
|
||
|
||
6. 如果 api-server 需要复用 token
|
||
- 优先读取项目内本地 CLI 配置中的 token，而不是硬编码或回填到 `.env`。
|
||
- 输出日志时统一 `[REDACTED]`。
|
||
|
||
排查要点：
|
||
- `ORDER BY` 和 private table 是两个独立问题，先分开修。
|
||
- 清库后旧 token 很可能不再能看见 private table，不代表表不存在。
|
||
- 若 `/v1/identity` 返回的 token 没权限，再检查当前 standalone 是否就是刚启动的本地实例、database 名是否一致、模块是否已重新发布。
|