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 回答