深入解析：PHP 后台通过权限精制飞书多维表格

关键词：飞书多维表格、PHP 权限模型、RBAC、API 令牌隔离、数据安全

在企业内部把「飞书多维表格」当轻量级业务数据库用时，权限粒度往往成为最后一道坎：
“能不能让 A 组的组长在 PHP 后台一口气维护 10 张表，而组员 B 只看得到其中 1 张？”
飞书原生权限做不到“组内再分层”，必须借助业务系统做二次封装。
本文给出一条可直接落地的「双层权限」方案：PHP 后台负责上层过滤，飞书 API 负责底层兜底，1000 字讲清模型、表结构、代码片段与踩坑点。

---

一、总体思路：把“表格”当“资源”再跑一次 RBAC

1. 用户 ⇨ 用户组 ⇨ 飞书表格，三层资源绑定。
2. PHP 后台维护 user_table_perms 关系表，决定“能看到谁”。
3. 飞书侧只给 PHP 应用 app_token，且通过“用户维度临时令牌”限制“能操作谁”。
4. 前端列表、后端接口、飞书 API 三层全部做权限校验，任一层拒绝都无法越权。

---

二、数据模型：4 张核心表够用

-- 用户组
CREATE TABLE user_groups (
group_id   INT AUTO_INCREMENT PRIMARY KEY,
group_name VARCHAR(64) UNIQUE
);
-- 用户
CREATE TABLE users (
user_id   INT AUTO_INCREMENT PRIMARY KEY,
group_id  INT NOT NULL,
is_admin  TINYINT(1) DEFAULT 0,
email     VARCHAR(128) UNIQUE,
INDEX idx_group (group_id)
);
-- 飞书表格
CREATE TABLE feishu_tables (
table_id   VARCHAR(32) PRIMARY KEY, -- 飞书返回的 tblxxxx
app_token  VARCHAR(64) NOT NULL,   -- 飞书应用凭证
table_name VARCHAR(128),
group_id   INT NOT NULL
);
-- 用户-表格权限
CREATE TABLE user_table_perms (
id        INT AUTO_INCREMENT PRIMARY KEY,
user_id   INT NOT NULL,
table_id  VARCHAR(32) NOT NULL,
perm_type ENUM('view','edit') DEFAULT 'view',
UNIQUE KEY uk_user_table (user_id, table_id)
);

说明：

• 管理员 is_admin=1 时，可在 user_table_perms 插入 N 行；普通用户只能插入 1 行。
• 表格必须归属某一 group_id，避免跨组越权。

---

三、配置流程：10 分钟完成“组管理员多表 / 普通用户单表”

1. 超管在「用户组管理」新建「华东区销售组」。
2. 在「飞书表格管理」把 5 张多维表格批量绑定到该组。
3. 勾选张三为「组管理员」，系统自动往 user_table_perms 写入 5 行 edit 权限。
4. 勾选李四为「普通成员」，下拉指定仅开放「客户跟进表」1 张，系统写入 1 行 view 权限。
5. 权限预览页可一键导出 Excel，方便审计。

---

四、代码实战：三处校验缺一不可

① 登录后取列表（伪代码）

$userId  = $_SESSION['user_id'];
$groupId = $_SESSION['group_id'];
// 一次性查出用户可见的表格
$tables = DB::select(
'SELECT t.*, p.perm_type
FROM feishu_tables t
JOIN user_table_perms p ON t.table_id = p.table_id
WHERE p.user_id = ? AND t.group_id = ?',
[$userId, $groupId]
);

返回 JSON 给前端，管理员拿到 5 个对象，普通用户仅 1 个。

② 操作前再校验（防 URL 伪造）

function checkTablePerm(int $userId, string $tableId, string $need = 'view'): bool
{
$row = DB::selectOne(
'SELECT perm_type FROM user_table_perms WHERE user_id = ? AND table_id = ?',
[$userId, $tableId]
);
if (!$row) return false;
return $need === 'edit' ? $row['perm_type'] === 'edit' : true;
}
// 在路由中间件调用
if (!checkTablePerm($userId, $inputTableId, 'edit')) {
http_response_code(403);
exit('无权限');
}

③ 飞书令牌范围隔离（底层兜底）

PHP 后台通过飞书身份验证换取 user_access_token 时，把 table_id 写进 scope：

"scope": {
"table:tblxxxx": ["READ", "WRITE"]
}

即使前端拿到令牌直接调飞书 API，也只能操作被授权的那 1 张表。

---

五、前端交互：让“看不见”等于“不存在”

• 表格列表使用 v-if 控制，无权限卡片直接不渲染，避免“置灰”带来的心理落差。
• 打开表格后，工具栏按钮根据 perm_type 动态生成：
  • view 仅显示“查询”、“导出”；
  • edit 再显示“新增记录”、“批量删除”。
• 所有写操作走统一 fetch 拦截器，后端返回 403 时自动弹窗“请联系管理员开通权限”。

---

六、常见坑位与排查清单

现象	90% 原因
管理员只看到 1 张表	user_table_perms 只插了 1 行，需“批量同步”按钮补录
普通用户仍能看到全部	漏加 t.group_id = ? 条件，被 SQL 查出跨组数据
飞书返回“No permission”	app_token 未在飞书后台开通“多维表格”权限集合
令牌 403，但 PHP 已放行	临时令牌 scope 写错，或 table_id 大小写不一致

---

七、小结

1. 把飞书表格当“资源”，PHP 跑一次标准 RBAC，模型简单可维护。
2. 管理员 / 普通用户的差异只体现在 user_table_perms 的行数，逻辑无分支，后期改需求只改数据。
3. 飞书侧只做“最低可用”授权，双重 403 让越权成本≈∞。
4. 前端“看不见”、后端“不给过”、API“不认账”，三层防护即可满足绝大多数合规审计。

按本文搭完后，后续新增表格或人员，只需在 PHP 后台“勾勾选选”5 秒搞定，再也不用追着飞书管理员到处开权限了。祝实施顺利！