是否有任何方法或架构设计模式可以实现安全，干净的基于角色/权限的访问控制和UI便利，而无需将它们耦合在一起？
长篇故事。
我在许多网络应用程序中看到了对角色和权限的模糊使用，我经常遇到这些含糊不清导致误解和实施困难。
这是一个简化的例子。
业务要求表示为某些特定角色设置的权限应拒绝访问显示完整地址列表的系统某些部分。但与此同时，此角色的用户需要在其他网页上读取自动填充列表的地址。
我已经看到鲁莽的开发人员如何创建一个权限条目来禁止访问地址，后来他们发现用户实际上需要从系统的其他部分读取地址。然后，他们为可以读取地址的特殊情况发明了另一个特定权限。
但对我而言，这似乎是模棱两可和潜在风险的情况。如果用户无法访问某些特定数据，则他/她根本无法访问它。期。仅为下拉列表添加特殊权限似乎是一个故意的安全漏洞。如果用户通过异步请求加载列表，并且服务器使用相同的控制器操作来返回列表（并且它应该 - 以避免代码重复），那么服务器将如何知道它何时不应返回地址，如果它们是有时禁止？
这种情况提出了一个问题：＆＃34; 为什么一些特定角色的用户不应该首先看到完整的地址列表，如果他们可以通过其他方式访问列表？ ＆＃34;我经常从业务分析师那里得到的答案就是＆＃34;嗯，出于数据安全原因，地址列表不是被禁止的，而是因为这个特定角色的用户不希望对地址列表做任何事情，它会在他们的工作区中是多余的项目＆＃34;。
所以，现在问题似乎很明显：一些权限仅用于控制UI，而不是严格控制对某些数据的访问。这种（ab）使用权限对我来说是错误的。因此，一开始就提出了这个问题。
答案 0 :(得分：2)
写得好！你觉得你已经有了答案。
IMO用户分析和用户访问不是一回事。访问权限应尽可能低地处理（例如，如果用户具有对特定SQL表的读访问权限），则在这种情况下的分析应仅适用于UI级别（＆＃34;用户实际需要的内容）或需要看＆＃34;）。
当我们谈论具有某种访问权限控制的应用程序时，几乎总是某种＆＃34;引擎＆＃34;实际拥有所有数据的UI背后。您可以做的最糟糕的事情是在引擎本身以外的任何地方实施安全性。除了通过引擎自己的访问控制之外，数据绝不能以任何其他方式访问，否则它不是访问控制 - 它的UI限制。
但这是一个完美的世界：/实际上，就像在所有工作领域一样，软件开发也越来越受到驱动，越来越具有成本效益，敏捷和对客户的响应。毫不奇怪，这引导人们做出快速而廉价的决定......就像＆＃34; 地狱，让我们制作另一个SQL程序，将数据作为管理员拉出来＆＃34 ;而不是＆＃34; 我们需要重新评估用户访问权限，和/或可能重新设计我们的表以保持与访问权限的一致性＆＃34;。当它完成时，它总是一个短期（坏）解决方案，但有些解决方案肯定比其他解决方案更多NO-NO。
作为一个指导原则，我要说如果你不确定自己在做什么，那么它就是最大的NO-NO。
TL; DR：如果某些数据即使在一个地方也应该可访问，则它不受访问控制的限制。如果在某处显示可访问数据是不必要的，请使用用户/应用程序分析对其进行过滤。