我的安全逻辑应该放在哪里？

Question

比方说，我有一个ASP.NET MVC Web应用程序调用的存储库层，它是建立在NHibernate的顶部。控制器通过资源库的ISecurityToken一个封装当前用户的身份和权限，查询只返回行的用户应该能够看到当仓库使用它。

我想要一个实体（机票）仅由特定的用户组，以及票被分配给该用户是可关闭的。换句话说，假设CanCloseTicket()方法需要两个输入：

1. 票本身（或其当前所有者ID）
2. 当前用户的ISecurityToken

应该在哪里这个假设的方法活？我可以看到几种可能性，但每种都有其缺点。

• 在控制器中：控制器可以访问所有必需的东西，但是这样可以让安全被绕过。 （“哎呀，我忘了在此操作中调用CanCloseTicket（），然后将ticket.IsOpen设置为false！”这味道不好。
• 在存储库中：存储库也可以访问这两个作品，但我也必须制作Ticket.IsClosed的设定装置专用于阻止发生上述同样的事情。这个仓库生活在一个完全不同的装配比这样使用内部制定者将无法正常工作模式，我可以代替离开的setter公众和属性的当前值比较其原一个，如果一个非特权用户关闭它会返回一个错误，但是这对我来说也有点味道（“哎呀，我忘了检查这个动作方法中的返回值repo.CloseTicket()！”）
• 在票证中：添加Ticket.Close(ISecurityToken token)，并让实体负责自己的安全逻辑感觉li违反SRP。

我认为知识库是这里最好的选择，但它感觉更像是最差的选项。还有别的事吗？

Answer 1

您的最终选择听起来恰到好处：当有人想要关闭一张票时，他们必须以安全令牌的形式提供证据。 （话虽如此，这已经够难判断SRP的侵犯，当你访问一个类的源代码，我不能说我完全有信心。）