一个权限管理小需求

大家好,我是鱼皮。最近在工作中遇到一个很有意思的小需求,并且我以一种很独特的方式解决了,今天就来给大家分享一下。

需求是这样的:

我们有一个 内部 的大数据任务调度系统,部门用户可以在该系统创建、删除和执行任务来获取数据。由于历史原因,目前系统的前、后端都加了严格的限制,只有该任务的创建者本人或者管理员才能修改和删除该任务。

现在的问题是:用户小 A 已经在系统上创建了很多任务,结果和他同组的小 B 入职了,之后这些任务要交给小 B 去维护和修改,因此小 B 也需要拥有对小 A 已创建的任务的修改权限。

补充一句,小 B 同学表示:非常着急。

那么,我们怎么实现这个需求呢?

实现同一个需求的方案有无限种,我的方案未必是最好的,所以就在 我的知识星球open in new window 里面开了个小的头脑风暴,看看大家的想法:

大家的讨论

大家的讨论非常积极,有很多的思路和我基本是一致的,整理一下,大概把方案分为 临时解决永久解决 两种类型。

临时解决

所谓临时解决,就是在 相对合理 的前提下,尽量最快、最高效的满足用户的需求。

对于咱们这个需求,我和小伙伴们第一时间想到了这些临时方案:

  1. 在代码中写一段 hardcode(硬编码),加个特殊的判断逻辑,只要任务创建者是小 A、操作者是小 B,也允许操作。有点类似继承?
  2. 移除对修改任务的权限校验,即所有同学都能修改任何任务。
  3. 将用户表中小 A 和小 B 的 id 进行替换,相当于两个人交换了身份证。
  4. 克隆小 A 的账户给小 B。
  5. 因为管理员能操作所有任务,所以可以给小 B 添加管理员权限。
  6. 开发一个模拟其他用户登录的接口,让小 B 可以模拟小 A 的身份登录。

这几种方案各有优缺。首先是第一个,要改代码、还要发布评审和上线、而且后面还得再把特殊逻辑去掉,挺麻烦,不采用;第二个方案就是公开权限,因为是内部系统、用户不多、而且默认只能看到自己创建的任务,所以我才敢这么想,但风险虽然没那么大、还是有风险的,所以不采用;第三个方案有点太粗暴了,相当于你为了干一件事临时和别人换了身份证,但是原本那个人所有任务之外的权限也会受到影响,肯定不行;第四个方案乍一听好像可行,但因为任务的创建者是关联了唯一的用户 id 的,克隆账户只是能产生一个有同样权限、新 id 的用户,所以并没有什么用;第五个方案也很粗暴,但因为管理员权限实在太大,也有安全风险,不采用。至于最后一个方案,为啥会想到模拟登陆呢?主要是我们系统已经有了这个接口(偷偷给管理员使用),其实只需要开放给用户就能快速以小 A 的身份去操作了,但这个接口本身存在一定风险,为了安全,也不采用。

这也不行、那也不行,还有什么更好的方法么?

我最后的方案是,直接修改数据库,将小 A 创建的任务的创建者为小 B。这种方案的好处是绝对的快、狠、准,不用改任何一行代码,而且因为总共就几个任务,所以改库也不是很麻烦。

当然,也没有说的那么简单,具体的实施过程是,我先对任务创建人这个字段的关联性进行了分析,确认修改字段不会对其他功能产生影响后,再找其他开发和产品二次确认了这样操作是否有风险。然后呢,跟用户(小 A、小 B)也确认了,是否之后小 A 不再参与编辑,全部交给小 B 负责,结果得到了确定的答复。接下来就先从一个任务入手,修改它的权限为小 B,再让小 B 试着去修改一下任务,确认没有问题后,再把其他任务的创建人也改掉,完美解决了需求~

这就是玩了一手移花接木啊,你想到这个方案了么?

对了,还有个很妙的方法,直接摆烂:劳资不做!让小 B 用小 A 的电脑来操作!

可能有些操作和设计长久来看是不合理的,但可以较低成本地临时解决问题,也是不错的方案,这就需要我们多思考、灵活变通。

永久解决

所谓的永久,并不是真的能一个方案贯彻到底,只是相对临时方案来说更稳定全面一些,能支撑系统更多时间。

对于咱们这个需求,其实永久解决的方案就很简单了吧,添加 权限管理体系 呗!

至于具体怎么权限管理,还是要根据系统用户的实际使用情况来设计,常见的几种设计如下:

  1. 授权,任务的创建者可以给其他角色分配修改权限,类似腾讯文档。这种方式最好理解,直接让小 A 给小 B 开权限即可。
  2. 权限组,任务的创建者可以给其他角色或 某个小组 的所有人分配修改权限。比如小 A 可以创建一个权限组,然后把小 B 拉到该组里,假如之后鱼皮也要有权限,把鱼皮也拉进来即可。
  3. RBAC,即基于角色的访问控制。它的核心思想是:将权限赋予给角色,把角色又赋予用户。是很灵活、很完整的权限管理设计了。比如小 A 创建 任务管理员角色 ,然后给小 B 分配 任务管理员角色 即可。

那后面我肯定是要给系统添加权限管理的,到时候我会选择哪个方案呢?

我大概率会选择方案 2。一般情况下来说,方案 1 开发最快,最好理解,但如果要同时给同组的很多人分配权限就很麻烦,增大了用户的操作成本;方案 3 虽然很灵活和完整,但开发成本最高,而且我们的这个系统并没有太多的 对象、角色、权限 ,用 RBAC 就有点大材小用了;而方案 2 相对最适用于当前的场景,并且由于系统本身就有权限组的管理功能,我只需要把任务和权限组关联起来就可以了,开发成本也是很低的。

你学 “废” 了么?

其实大部分的方案星球的小伙伴们都想到了。不过除了这些方案外,也出现了我未曾想过的道路:

对于某种特殊情况,万一这个操作是最合适的呢???

(扯淡!千万别试!)

加入星球

👉🏻 点此加入星球