design-patterns - 在哪里应用域级权限

Question

我认为许可/授权(而非身份验证)是一个跨领域的关注点。

在洋葱架构或六边形架构中，应该在哪里执行许可？所需许可的示例是:

• 过滤返回到前端(UI、API 或其他)的数据
• 验证业务操作完全可以执行

理想情况下，根据单一职责原则，执行业务操作和返回数据的代码根本不需要知道用户的权限。该功能的实现应该知道如何执行业务操作或查询存储库或域服务 - 仅此而已。

实现与执行业务操作或返回数据的类相同的接口(interface)的包装器/外观是否是放置此权限的地方？或者有更好的方法吗？

此外，如果最佳实践是按事件而不是按角色授予权限，那么说权限应该由仅用于返回数据的服务来执行是否仍然有效？

Answer 1

有人可能会争辩说，访问检查应该始终尽可能靠近执行操作的代码，以减少有人找到绕过访问检查的旁路的机会。也就是说，如果您可以使用包装类来保证在生产系统中访问检查将始终存在，我认为这很好。

Validating that a business operation can be performed at all

我发现将确定操作是否可以执行的访问检查放在包装器中是很自然的。包装器代码通常是简单的胶水，可以理解传递给 protected 函数的参数，并将这些参数转换为适合做出授权决策的形式。

Filtering data returned to the front end (UI, API, or otherwise)

我假设您的意思是根据调用者的权限从查询的响应中过滤出行。例如，如果部门经理查询每个人的薪水，则经理将只返回向他/她报告的人的薪水，因为他们无权访问其他人的薪水。

对于这种类型的过滤，我从未找到将其实现为横切关注点的方法。我要么将过滤融入业务逻辑，要么退回到一个模型，该模型由于缺乏权限而拒绝执行查询。

我遇到的问题是，要启用过滤，安全代码必须查看返回的数据并能够将权限与其相关联。在简单情况下执行此操作似乎需要大量工作，而在复杂情况下则非常麻烦(想象一下返回的数据集是多个数据库操作的连接)。

也就是说，我并不反对内容过滤。我只是还没有看到一个好的解决方案。