Model view controller 为什么在MVC中，auth通常位于控制器中？

我已经为不同的MVC框架做了很多教程，在控制器中进行授权似乎非常典型。为什么?

我的想法是，控制器应该只用于编排模型操作、处理重定向和处理错误事件。这些都取决于具体的请求。将授权放在控制器中，似乎每当您在不同的控制器操作或不同的控制器中使用相同的模型操作时，都必须复制授权。如果模型中有Auth，则对数据执行操作或状态更改的要求是一致的

我一直在谷歌上搜索和研究其他问题，例如，但我真的不明白为什么这是公认的惯例

将授权置于控制器中而不是模型中，是否有我遗漏的具体原因？

总结评论中的要点：

• 控制器负责更改模型层和当前视图的状态。没有别的了
• 授权属于执行操作的地方，如果您遵循严格的MVC模式，那么这很可能就是模型，控制器当然不负责授权使用模型操作
• cookie应该像对待任何其他数据存储一样：抽象并在模型中使用，而不是直接由控制器使用
• 身份验证和授权是两个独立的问题，尽管它们通常都位于模型层，因为它们通常涉及对数据存储中的值（如cookie）的检查

---

授权作为一个完整的过程，应该同时涉及控制器层和模型层

但是，所有的logc（SQL查询等）都应该在模型中发生。 控制器是视图（表示）和模型之间的中间层。 但是，您不能将控制器从这个方案中丢弃，因为控制器负责处理会话和cookie。如果没有这两件事，所有的身份验证/授权逻辑都是无用的，因为它本质上是无状态的。会话和Cookie为它带来状态。 此外，正如您正确提到的，控制器负责重定向

是否有一个具体的原因，我没有把授权在控制器上的模型

我能想象的最常见的原因是懒惰。我的意思不是说，从道德上讲，将一些授权概念分散到更接近具体请求的层比在模型层上进行差异化访问要容易得多。对模型进行授权是一种更高的设计

为了给答案添加一些更实际的建议，我认为您应该分析每个项目在何处以及您希望引入授权的内容。这方面的需求可能（极其）不同

---

然后，只有在下一步中，您才应该考虑哪种设计最有利于引入授权和身份验证来满足这些需求。

在MVC方法中，您需要将安全性放在以下位置：

这是无法回避的

它可以很容易地进行配置、管理和更新

事实上，这适用于任何体系结构/应用程序类型

具体来说，在MVC中，假设您将授权放在视图中。例如，您决定通过启用/禁用按钮来控制谁可以批准交易。如果您视图的用户不被允许，他/她将无法批准交易。现在想象一下，您通过API而不是视图公开了控制器。批准授权检查现在需要在API层中重新实现

本例表明，最好将授权从视图/不同的端点移动到一个公共的中心点—控制器

类似地，如果您希望控制对大型数据集（例如医疗记录）的访问，理想情况下您希望将授权放在模型中。这既是出于性能原因，也是出于安全原因：您宁愿让控制器处理较少的数据，并且应始终努力保护尽可能靠近敏感数据源的数据

请注意，同时在视图、控制器和模型中进行授权挂钩/检查可能会带来全面增强的体验。将视图中的授权视为一种“安全性/可用性”机制，用户只能根据其权限在屏幕上显示那些相关的菜单和小部件。如果他们是恶意的，并且知道如何绕过UI到达控制器，那么授权仍然会生效

---

最后，一般来说，您希望将非功能性需求/逻辑与功能性需求/逻辑解耦。就像您不实现登录代码，而是使用可配置的框架（如Log4J）或依赖容器进行身份验证（如Apache Tomcat中的HTTP BASIC），您希望使用外部化的授权框架，如Microsoft MVC4世界中基于声明的授权、Java中的Spring Security、Ruby中的CanCan或XACML中的基于声明的授权，与SAML（OASIS）相同主体的标准部分，允许您对任何类型的应用程序和任何层应用授权。

我想说的是，it控制器和模型层都不应该与授权检查有关。人们大多将其转储到“控制器”中，因为在使用类似Rails的体系结构时，他们会在“控制器”中转储其他所有内容。我使用的是一个具有授权规则的类，但您实际在哪里执行强制？如果不在控制器或模型中，你在哪里说“要做到这一点，你必须通过这些规则”？嗯。我在你的评论中读到有规则。我想说的是，这些规则应该已经给了你一些指向它们所涉及的东西的指针。@Charles，我想说的是