|
|
@@ -128,6 +128,18 @@
|
|
|
-- 2. 把 `save` / `delete` 的权限从 `merchant:list` 换成写专用权限,且该权限**不授给 role 2**
|
|
|
-- (即:映射表由运营维护、租户只读)。
|
|
|
--
|
|
|
+-- ★★ 2026-09-30 追记:**条件 2 已经成立**,而且比字面写法更彻底 ——
|
|
|
+-- `save` / `delete` 已不再挂任何权限串,改挂**超管身份** `@perm.hasRole('SUPERUSER')`
|
|
|
+-- (提交 `5db0155b`,用户裁定「新增商户号是超管操作…租户不允许自己录入商户号」)。
|
|
|
+-- 比「换一个不授给 role 2 的写专用权限串」更强:权限串本身是可再授给任意角色的,
|
|
|
+-- 而身份门禁授不出去。⇒ 上面那条攻击链的**第一跳**(租户自己往映射表写一行)
|
|
|
+-- 今天走不通了,「映射表由运营维护、租户只读」也成为字面事实。
|
|
|
+-- ⚠ **但本脚本没有据此改动**:是否把进件页开给 role 2 是**产品决定**
|
|
|
+-- (租户该不该自助进件),不是这次改动的推论;本次裁定的方向恰恰是收紧而非放开。
|
|
|
+-- 真要放开,按上面那条 INSERT 单独跑,**不要重跑本脚本**。
|
|
|
+-- 放开前请重新核对**条件 1**(`/commit` 的归属闸仍只证明「本租户内存在这一行」,
|
|
|
+-- 不由构造保证),以及 `merchant:list` 今天依然同时守着 `page`(读)。
|
|
|
+--
|
|
|
-- ★ 放开时**不要重跑本脚本**(页面行已存在 ⇒ `page` 为空 ⇒ 授权行也不会插,见下面「幂等」)。
|
|
|
-- 单独跑这一条即可:
|
|
|
-- INSERT INTO sys_role_menus (role_id, menu_id)
|