2

语境

  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 代表必须“成为”卖方的方法。有一定的清洁度（因为它确实将安全模型集中在域而不是用例上）。（注意将进行充分的审计以检测某人何时代表他人行事）

意见？

4

2 回答 2

0

我认为您正在做的是一个好主意（我目前正在做类似的事情）。

我建议您看一下 Spring Security 中的 PermissionEvaluator 组件（请参阅此处），因为它比普通注释具有一些优势

  1. 您的安全机制可以更容易地更改，因为它更加全球化
  2. 安全评估可以通过审计日志/监控/...轻松扩展
  3. Evaluator 实现可以进行单元测试（注释需要运行 spring 上下文才能工作，因此只能在集成测试中进行测试）

到目前为止，我没有发现这个想法的直接缺点。

于 2012-05-01T22:17:55.727 回答
0

我认为你做得完全正确。当你说安全是一个正交的问题时，正交于什么？当你说这应该是业务逻辑的一部分时，你是 110% 正确的。

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

考虑到在这种情况下安全性的重要性，我希望你会编写一个单元测试的垃圾风暴，在给定附加到选项的角色的情况下展示适当的结果。

于 2012-05-01T18:49:18.797 回答