【问题标题】:Security and Access control in a MVC applicationMVC 应用程序中的安全和访问控制
【发布时间】:2010-09-22 10:06:47
【问题描述】:
我最近才开始使用 MVC 方法,所以我想这对各位大师来说很容易:
我应该把访问控制放在哪里?
- 在视图中?除了开关和标志之外,我不想在我的模板中有任何逻辑,所以这听起来是最不可行的选择
- 在模型中?每个业务对象是否应该根据谁的要求来决定它会透露哪些关于自己的数据?
- 在控制器中?这就是我现在拥有的地方,但它很难保持业务规则的一致性
或者还有其他选择吗?
【问题讨论】:
标签:
security
model-view-controller
access-control
【解决方案1】:
对于模型(又名数据)安全性,模型将“控制”访问,而控制器将“促进”访问。这提供了独立于控制器的模型的重用,并最大限度地减少了使用模型的不同控制器之间所需的通用代码复制。
例如汽车、司机和钥匙。 (分别为模型、控制器、API)。凭借非常小的接口(密钥 == API),模型允许或拒绝每个 API 的控制器访问(密钥卡)。允许不同类型的访问(代客钥匙、所有者钥匙、所有者 FOB)。使用代客钥匙界面,控制器将无法访问模型的某些数据/功能,例如手套箱、行李箱和油箱。这本质上是由模型通过识别和分类具有非常小的 API/命令表面积的控制器来实现的基于角色的访问。
这意味着该模型可以被其他控制器(具有不同驱动程序的汽车)使用,这些控制器只需要基本的身份验证就可以访问模型的数据(汽车的功能和车厢)。
【解决方案2】:
这取决于您使用的框架,而语言将决定您可以使用的许多工具。
从高层次上讲,您应该在入口点配置访问安全性。并且您应该仔细检查每个级别的访问安全性,这些级别可以被认为是自主的或从应用程序的多个部分重用(谁知道是否由使用您的逻辑层的同事的门户检查了安全性?等等)。另一件需要担心的是数据安全性,它属于尽可能接近您的数据(所以,对上面的#2 是的,但要理解它是独立的)。
这类似于我喜欢谈论的应用程序逻辑和域逻辑之间的区别。如果有任何特定于某个特定应用程序的逻辑(Web 应用程序与 Windows 服务相比,或其他),则该逻辑应仅在该应用程序中定义。如果某些逻辑跨越了应用程序之间的边界(可在应用程序之间重用),那么它就有资格作为域逻辑并且应该在您的模型中定义。您的应用程序可以使用域逻辑,但它们不应该拥有它。