如何避免滥用角色和权限来控制用户界面？

Question

有没有方法或架构设计模式可以实现安全、清晰的基于角色/权限的访问控制和UI便利，而不将它们耦合在一起？

长话短说，我看到很多Web应用程序中对角色和权限的使用含糊不清，并且我经常遇到这些歧义导致的误解和实现困难。

以下是一个简化的例子。业务需求要求某个特定角色的权限集应该禁止访问显示完整地址列表的系统的某些部分。但同时，这个角色的用户需要在其他网页上的自动完成列表中读取地址。

我看到过粗心的开发人员创建一个权限条目来禁止访问地址，后来他们发现用户实际上需要从系统的其他部分读取地址。然后他们为特殊情况发明了另一个特定的权限，其中地址可以被读取。

但对我来说，这似乎是一个模糊不清且可能存在风险的情况。如果用户无法访问某些特定数据，则他/她根本就不应该能够访问它。添加一个专门的权限仅用于下拉列表似乎是一个故意的安全漏洞。如果用户通过异步请求加载列表，并且服务器正在使用相同的控制器操作返回列表（应该这样做以避免代码重复），那么当它们有时被禁止时，服务器将如何知道何时不返回地址？

这种情况引发了一个问题：“如果某些特定角色的用户可以通过其他方式访问列表，为什么他们一开始就不能看到完整的地址列表？”而业务分析师经常给出的答案是“好吧，地址列表不是因为数据安全原因而被禁止，只是因为这个特定角色的用户不需要对地址列表进行任何操作，它将成为他们工作区的多余项目”。

因此，现在问题对我来说似乎很清楚：一些权限存在仅用于控制UI而不是严格控制对某些数据的访问。这种(滥)用权限让我感到不舒服。因此，这就是一开始提出的问题。

- JustAMartin

Answer 1

写得不错！感觉你已经有了答案。

在我看来，用户配置文件和用户访问权限并不相同。访问权限应该尽可能地以低级别处理（例如，一个用户是否具有对特定SQL表的读取访问权限），而在这种情况下，配置文件只应用于UI级别（“用户实际想要或需要看到什么”）。

当我们谈论具有某种访问权限控制的应用程序时，几乎总会有某种在UI后面的“引擎”，它实际上保存了所有数据。你可以做的最糟糕的事情就是在引擎本身之外的任何其他地方实现安全性。数据绝不能以任何方式通过该引擎自己的访问控制以外的方式访问，否则它就不是访问控制 - 它是UI限制。

但那是完美的世界：/在现实中，就像工作的所有领域一样，软件开发也被推向更加成本效益高、敏捷和响应客户的方向。毫不奇怪，这引导人们做出快速而廉价的决策……比如“去吧，让我们再写一个SQL过程，以管理员身份提取数据”而不是“我们需要重新评估用户访问权限，并/或者重新设计我们的表以保持与访问权限的一致性”。当它被做时，它总是一个短期（糟糕）的解决方案，但有些解决方案绝对比其他解决方案更加NO-NO。

作为指南，我会说，如果你不确定自己在做什么，那就是最大的NO-NO。

TL;DR：如果某些数据应该在一个地方可访问，那么它就不受访问控制限制。如果在某个地方显示可访问的数据是不必要的，请使用用户/应用程序配置文件进行过滤。

- Simo Erkinheimo