如何避免滥用用户界面的角色和权限？
How to avoid abusing roles and permissions for user interface?
是否有任何方法或架构设计模式可以在不将它们耦合在一起的情况下实现安全、干净的基于 role/permission 的访问控制和 UI 便利？
说来话长。
我在许多 Web 应用程序中看到过角色和权限的模糊使用，并且我经常体验到这些模糊是如何导致误解和实施困难的。
这是一个简化的例子。
业务需求表明，某些特定角色的权限集应该拒绝访问显示完整地址列表的系统的某些部分。但与此同时，此角色的用户将需要读取其他网页上自动完成列表的地址。
我看到鲁莽的开发人员如何创建一个权限条目来禁止访问地址，后来他们发现用户实际上需要从系统的其他部分读取地址。然后他们为可以读取地址的特殊情况发明了另一种特定权限。
但对我来说，这似乎是模棱两可且具有潜在风险的情况。如果用户无权访问某些特定数据，则 he/she 根本无法访问它。时期。仅为下拉列表添加特殊权限似乎是故意的安全漏洞。如果用户通过异步请求加载列表并且服务器正在使用相同的控制器操作来 return 列表（它应该 - 避免代码重复），那么服务器将如何知道它什么时候不应该 return 地址，如果它们有时 被禁止？
这种情况提出了一个问题：“如果某些特定角色的用户可以通过其他方式访问列表，为什么他们不应该首先看到完整的地址列表？" 我经常从业务分析师那里得到的答案是 "Well, the address list is not forbidden for data security reasons, but just because users of this particular role are not expected to do anything with the address list and it would be redundant item in their workspace".
所以，现在问题对我来说似乎很清楚：有些权限只是为了控制 UI 而不是严格控制对某些数据的访问 。这种（滥用）权限的使用对我来说是错误的。所以一开始就提的问题
写得好！感觉你已经有了答案。
IMO 用户分析和用户访问不是一回事。访问权限应尽可能低级别处理（例如，如果用户对特定 SQL table 具有读取权限），并且在这种情况下的分析应仅适用于 UI 级 ("what the user actually wants or needs to see").
当我们谈论具有某种访问权限控制的应用程序时，UI 背后几乎总是有某种 "engine" 实际保存所有数据。您能做的最糟糕的事情就是在引擎本身以外的任何地方实施安全性。除了通过该引擎自己的访问控制之外，绝不能以任何其他方式访问数据，否则它不是访问控制 - 这是 UI 限制。
但那是完美的世界:/ 实际上，就像在所有工作领域一样，软件开发也一直朝着更具成本效益、敏捷和响应客户的方向发展。毫不奇怪，这会引导人们做出快速而廉价的决定......比如“见鬼，让我们再做一个 SQL 程序，以管理员 的身份提取数据”而不是“我们需要重新评估用户访问权限，and/or 可能会重新设计我们的 table 以与访问权限保持一致”。当它完成时，它总是一个短期的（坏的）解决方案，但有些解决方案肯定比其他解决方案更不可取。
作为准则，我会说，如果您不能 110% 确定自己在做什么，那就是最大的禁忌。
TL;DR：如果某些数据即使在一个地方也应该可以访问，那么它就不受访问控制的限制。如果不需要在某处显示可访问的数据，请使用 user/application 分析来过滤它。
是否有任何方法或架构设计模式可以在不将它们耦合在一起的情况下实现安全、干净的基于 role/permission 的访问控制和 UI 便利？
说来话长。
我在许多 Web 应用程序中看到过角色和权限的模糊使用，并且我经常体验到这些模糊是如何导致误解和实施困难的。
这是一个简化的例子。
业务需求表明，某些特定角色的权限集应该拒绝访问显示完整地址列表的系统的某些部分。但与此同时，此角色的用户将需要读取其他网页上自动完成列表的地址。
我看到鲁莽的开发人员如何创建一个权限条目来禁止访问地址，后来他们发现用户实际上需要从系统的其他部分读取地址。然后他们为可以读取地址的特殊情况发明了另一种特定权限。
但对我来说，这似乎是模棱两可且具有潜在风险的情况。如果用户无权访问某些特定数据，则 he/she 根本无法访问它。时期。仅为下拉列表添加特殊权限似乎是故意的安全漏洞。如果用户通过异步请求加载列表并且服务器正在使用相同的控制器操作来 return 列表（它应该 - 避免代码重复），那么服务器将如何知道它什么时候不应该 return 地址，如果它们有时 被禁止？
这种情况提出了一个问题：“如果某些特定角色的用户可以通过其他方式访问列表，为什么他们不应该首先看到完整的地址列表？" 我经常从业务分析师那里得到的答案是 "Well, the address list is not forbidden for data security reasons, but just because users of this particular role are not expected to do anything with the address list and it would be redundant item in their workspace".
所以，现在问题对我来说似乎很清楚：有些权限只是为了控制 UI 而不是严格控制对某些数据的访问 。这种（滥用）权限的使用对我来说是错误的。所以一开始就提的问题
写得好！感觉你已经有了答案。
IMO 用户分析和用户访问不是一回事。访问权限应尽可能低级别处理（例如，如果用户对特定 SQL table 具有读取权限），并且在这种情况下的分析应仅适用于 UI 级 ("what the user actually wants or needs to see").
当我们谈论具有某种访问权限控制的应用程序时，UI 背后几乎总是有某种 "engine" 实际保存所有数据。您能做的最糟糕的事情就是在引擎本身以外的任何地方实施安全性。除了通过该引擎自己的访问控制之外，绝不能以任何其他方式访问数据，否则它不是访问控制 - 这是 UI 限制。
但那是完美的世界:/ 实际上，就像在所有工作领域一样，软件开发也一直朝着更具成本效益、敏捷和响应客户的方向发展。毫不奇怪，这会引导人们做出快速而廉价的决定......比如“见鬼，让我们再做一个 SQL 程序，以管理员 的身份提取数据”而不是“我们需要重新评估用户访问权限，and/or 可能会重新设计我们的 table 以与访问权限保持一致”。当它完成时，它总是一个短期的（坏的）解决方案，但有些解决方案肯定比其他解决方案更不可取。
作为准则，我会说，如果您不能 110% 确定自己在做什么，那就是最大的禁忌。
TL;DR：如果某些数据即使在一个地方也应该可以访问，那么它就不受访问控制的限制。如果不需要在某处显示可访问的数据，请使用 user/application 分析来过滤它。