我认为权限/授权（不是身份验证）是一个贯穿各领域的问题。
在洋葱建筑或六角形建筑中，应该在哪里进行许可？需要许可的例子是：
理想情况下，通过单一责任原则，执行业务操作和返回数据的代码根本不需要了解用户的权限。该功能的实现应该知道如何执行业务操作或查询存储库或域服务 - 就是这样。
执行业务操作或返回数据的类实现相同接口的包装器/外观是否可以放置此权限？或者有更好的方法吗？
此外，如果最佳做法是通过活动而不是角色进行许可，那么说服务的目的仅仅是返回数据是否仍然有效？
答案 0 :(得分：2)
有人可能会争辩说，访问检查应该始终尽可能接近执行操作的代码，以减少某人找到绕过访问检查的旁道的机会。也就是说，如果您可以使用包装类，以保证在生产系统中访问检查将始终存在，我认为这很好。
验证是否可以执行业务操作
我发现将访问检查确定是否可以在包装器中执行操作是非常自然的。包装器代码通常是简单的粘合剂，它可以理解传递给受保护功能的参数，并将这些参数转换为适合做出授权决策的形式。
过滤返回前端的数据（UI，API或其他）
由此我假设您的意思是根据调用者的权限从查询的响应中过滤行。例如，如果部门经理对每个人的工资进行查询，那么经理只会返回向他/她报告的人员的工资，因为他们没有权限访问其他人的工资。工资。
对于这种类型的过滤，我从未找到过将其作为横切关注点实现的方法。我已经对业务逻辑进行了过滤，或者退回到一个模型，该模型由于缺乏权限而拒绝允许查询执行。
我遇到的问题是，要启用过滤，安全代码必须查看返回的数据并能够将权限与其关联。在简单的情况下执行此操作似乎是相当多的工作，并且在复杂的情况下是彻头彻尾的毛茸茸（假设返回的数据集是多个数据库操作的连接）。
那就是说，我不反对内容过滤。我还没有看到一个很好的解决方案。
答案 1 :(得分：0)
按活动的权限是您拥有授权API正在检查的权限和活动的位置。这与角色和权限相同，并且通过检查我们已指定授权角色的业务对象的权限来完成授权。这提供了灵活性，因为唯一修复的是权限，但我们可以拥有不同的角色 - 在DB中完全独立于权限定义。
将授权逻辑与服务完全分离的一种方法和返回要显示的对象的Business层是使用自定义授权属性。在这些属性中，您可以指定用户需要具有哪些权限才能在MVC控制器中执行操作。
检索用户具有权限的业务对象，并在调用服务或存储库时将其用作输入，这是将授权逻辑与服务逻辑分离的好方法。例如，我是用户x，可以访问客户y，t，g和l - 给我所有客户的订单。