寻求的意见：建筑蓝图，例如关卡安全

Question

上下文

1. 卖家列出物品的商业市场
2. 有一个操作Item :: setPrice
3. 商品的销售商或客户服务代表可以更改商品的价格。
4. ＃3的安全检查在项目的数据访问层附近实施，以便最大化安全检查的覆盖范围。

很多人都喜欢将安全性作为正交关注进行讨论，但是我（目前？）没有参与其中，尤其是在考虑实例级安全性时，因为它与之无关紧要。领域模型。底线是，我实际上更喜欢，＃3中的安全不变量在代码中明确说明（通过代码或通过Spring Security EL注释）。我认为这些安全不变量是业务逻辑的一部分。我也希望开发人员面对安全。它与IMO的责任不正确。

我可能会写一些类似的东西：

@PreAuthorize("hasRole('CSR_ITEM_WRITER') or #item.seller.id == principal.id')
public void setPrice(Item item, Money price) { ... }

我意识到这在创建安全模型时会产生一定程度的不灵活性（但考虑到错误的含义，这是一件坏事吗？）

我们还讨论了CS Rep必须“成为”卖方的方法。这有一定的清洁度（因为它确实围绕域而不是用例关注安全模型）。 （N.B。将进行足够的审核以检测某人是否代表他人行事）

评论

Answer 1

我认为你做得恰到好处。当你说安全是一个正交的问题，正交什么？当你说这应该是业务逻辑的一部分时，你是110％的权利。

我会保留REP和卖方之间的分离。两者都是独特的角色;对于这种特殊情况，它们碰巧有重叠。

鉴于在这种情况下对安全性的重要程度，我希望你会编写一个单独测试的风暴，以证明给定附加角色的适当结果。

Answer 2

我认为你所做的是一个好主意（我现在正在做类似的事情）。

我建议你看一下Spring安全性中的PermissionEvaluator组件（参见here），因为它比普通的注释有一些优势

1. 您的安全机制可以更容易更改，因为它更加全球化
2. 安全评估可以通过审核日志/监控/...
轻松扩展
3. Evaluator实现可以进行单元测试（注释需要运行弹簧上下文才能工作，所以它们只能在集成测试中测试）
到目前为止，我发现这个想法并没有直接的缺点。