MVC 应用程序中的安全性和访问控制
我最近才开始使用 MVC 方法，所以我想这对于各位专家来说是一个简单的方法：
我在哪里放置访问控制？
- 在视图中？ 除了模板中的开关和标志之外，我不想有任何逻辑，所以这听起来像是
- 模型中最不可行的选项？ 每个业务对象是否应该根据谁的询问来决定将透露哪些有关自身的数据？
- 在控制器中？ 这就是我现在拥有的地方，但它很难保持业务规则一致
或者还有其他选择吗？
I have only recently started working with the MVC approach, so I suppose this is an easy one for you gurus here:
Where do I put access control?
- In a view? I don't want to have any logic besides switches and flags in my templates, so that sounds like the least viable option
- In the model? Should each business object decide what data it will reveal about itself based on who's asking?
- In the controller? That's where I have it now but it makes it hard to keep business rules consistent
Or is there another option?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这将取决于您使用的框架，并且语言将决定您可以使用的许多工具。
从较高的层面来看，您应该在入口点配置访问安全性。 您应该仔细检查每个级别的访问安全性，这些级别可以被认为是自主的或从应用程序的多个部分重用（谁知道安全性是否由使用您的逻辑层的同事的门户进行了检查？等等）。 另一件需要担心的事情是数据安全，它尽可能接近您的数据（所以，上面的#2 是的，但要明白它是独立的）。
这类似于我喜欢谈论的应用程序逻辑和领域逻辑之间的区别。 如果存在特定于某个特定应用程序的任何逻辑（与 Windows 服务相比的 Web 应用程序或其他应用程序），则应仅在该应用程序中定义该逻辑。 如果某些逻辑跨越应用程序之间的边界（在应用程序之间可重用），那么它就符合域逻辑的资格，并且应该在您的模型中定义。 您的应用程序可以使用域逻辑，但它们不应该拥有它。
This will depend on what framework you're using as that and the language will dictate a lot of the tools you have available to you.
From a high level, you should have access security configured at points-of-entry. And you should double-check access security at every level that could be considered autonomous or reused from multiple parts of your application (who knows if security was checked by your co-worker's portal that uses your logic layer? etc.). The other thing to worry about is data security, and that belongs as close to your data as possible (so, yes to your #2 above, but understand that it's separate).
This is akin to the difference between application logic and domain logic, which I'm fond of talking about. If there is any logic that is specific to one particular application (web app compared to a windows service, or whatever) then that logic should be defined in that application only. If some logic crosses the boundary between applications (is reusable between applications) then it qualifies as domain logic and should be defined in your model. Your applications can make use of domain logic, but they should not own it.
对于模型（又名数据）安全性，模型将“控制”访问，控制器将“促进”访问。 这提供了独立于控制器的模型的重用，并且即使不能消除使用该模型的不同控制器之间所需的一般代码复制，也可以最小化。
例如，汽车、驾驶员和钥匙。 （分别为模型、控制器、API）。 凭借非常小的接口（密钥== API），模型允许或拒绝每个 API（密钥卡）的控制器访问。 允许不同类型的访问（代客钥匙、所有者钥匙、所有者 FOB）。 使用代客钥匙接口，控制器将无法访问模型的某些数据/功能，例如手套箱、行李箱和油箱。 这本质上是模型通过使用非常小的 API/命令表面积对控制器进行识别和分类来实现的基于角色的访问。
这意味着该模型可以被其他控制器（具有不同驾驶员的汽车）使用，只需要基本身份验证即可访问模型的数据（汽车的功能和车厢）。
For Model (aka data) security, the Model would "control" the access and the Controller would "facilitate" the access. This provides for the reuse of the Model independently of the Controller and minimizes if not negates the general code replication necessary across dissimilar Controllers which use the Model.
For example a Car, a Driver, and a Key. (Model, Controller, API respectively). By virtue of a very small interface (key == API), the Model permits or denies Controller access per API (key fob). Different types of access are permitted (Valet key, Owner Key, Owner FOB). Using the Valet key interface, the Controller will not have access to some of the data/function of the Model such as the glove compartment, the trunk and the gas tank. This is essentially role based access implemented by the Model through identifying and categorizing the Controller with a very small API/command surface area.
This means that the Model can be used by other controllers (car with different drivers) which only need the basic authentication to access the data of the model (functions and compartments of the car).