逃坑威龙：来时无声，去时留踪

最近踩了几个不常见的坑，人虽然没emo，但是填坑那几天的精气神到底是有些不足。

这些天的经历过于丰富，一时间想不到语言去形容。所以我画了幅图，并取了个好听的名字——"逃坑威龙"。

虽然不排除，今后还会经历踩坑、填坑、再入新坑的循环。至少，这个短暂的时期内，我是处于写"万字感言"的阶段。

于是有了前一篇代码设计闭坑思路，也有了今天这篇数据权限的思考。

数据权限：可算是触发隐藏副本了

从权限控制说起吧

最近购物节，张三购买了不少日用品，当他打开自己的订单页面的时候，发现了一条不认识的购买记录，细看是李四的。好家伙，这买的是什么，没想到你是这样的李四。

正常这种情况是不会出现的，因为开发者会做数据权限设计：

虽然看上去只有一句话，很好理解，好像很简单。但是实际情况，系统的权限层级不是单一的，随着层级的增加，不同层级的权限会出现交叉、包含等情况。

举个例子：

使用RBAC模型就可以实现基于角色的访问权限控制。

但是，实际业务场景中，除了角色还有更细小的权限控制，所以常规的权限控制的规则设计无法覆盖全。

隐藏副本：数据导出

做完权限管理，我遇到的第一个隐藏副本（掉坑），就是数据导出。

我们导出的那套系统是公共的，跟权限系统是分开的。

在没有任何特殊处理的情况下，某个角色是可以导出所有角色数据的。

原来不止人类的悲喜，系统也是不相通的。

后来，我在导出操作的方法中加入了当前角色的信息，才做到了数据的隔离。

数据导出的时候，除了需要传入筛选项的值，还需要默认带上用户的信息。

/**
 * 数据导出公共方法
 * @param {Object} 搜索项筛选数据对象
 */
const export = (searchParams) => {
  const userInfo = JSON.parse(sessionStorage.getItem('userInfo') || '{}');
  let params = {
    ...searchParams,
    ...userInfo.
  }
}

<Button type="primary" onClick={() => util.export({ ...listRef.current.searchParams() })} >
  导出
</Button>

当初就应该多看它几眼。

隐藏副本：不受控的"手动挡"

角色权限控制确实好用，但是也不是"万金油"。这不，我又触发了一次隐藏副本（掉坑）。

接续上面提到的活动的场景

我也凌乱了。

总结

谈到数据权限，第一时间想到的是通过请求数据增加过滤条件进行数据的筛选，其实前端技术层面也可以做限制的。

这也是我在摸索过程中得到的启发。

作者：非职业「传道授业解惑」的开发者叶一一
简介：「趣学前端」、「CSS畅想」系列作者，华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。