授权应该是模型或控制器的一部分吗？

Question

我正在编写一个具有一些 ACL 要求的 Web 应用程序：用户可以更改某些项目，某些项目可以由多个用户编辑，管理员可以编辑任何内容，经理可以编辑其组织内的所有内容等。

我正在使用玩！框架，并且从 Secure 模块的外观来看，放置授权问题的地方似乎是在控制器中。然而，在我看来，授权问题是业务逻辑的一部分，因此应该在模型中。此外，我开始在控制器中看到需要重构的重复逻辑。

另一方面，向模型添加授权意味着我必须有某种方法从模型中获取当前用户，这似乎不对。或者，我可以向每个模型方法添加一个“current_user”参数，但这似乎更糟糕。

那么常见的做法是什么呢？我可以/应该将授权代码放入模型中，还是将其保留在控制器中？

Answer 1

授权不应成为控制器或域模型的一部分。

相反，它应该位于服务层。

控制器应该只充当 HTTP 和应用程序服务之间的调度程序和委托。
这是进行编排的应用程序服务。这是放置授权的最佳位置。

假设用户 A 被授权访问域 X 中的数据，但没有被授权对域 Y 中的数据进行读取访问。如果将授权置于控制器中，则用户 A 在控制器 X 中获得授权，并且通过服务调用可以从域 Y 访问数据，这不是我们所期望的。

由于领域模型在服务层上相互通信，因此最好将授权放在同一级别。

Answer 2

我认为这是一个灰色地带。有人可能会说，用户访问是 HTTP 世界和面向对象世界之间映射的一部分。这就是控制器的目的（因此大量使用静态），转换传入的请求，准备处理域模型上的业务规则。

我建议控制器逻辑绝对是控制模型访问的正确位置，特别是因为这主要在注释级别进行管理，并且身份验证被抽象到安全类。

Answer 3

在大多数情况下，安全性应该位于模型之上的一层（或多层）。安全性是一个独立的域，限制对较低级别的访问。

我认为安全性不应该在控制器级别完成。

在我看来，这应该是这样的：

查看 ->控制器->安全->模型

安全层可以是模型的外观或代理，保护访问，但对控制器是透明的。

但是，如果要根据用户的访问权限修改视图，则可能必须在控制器级别进行一些检查（例如在 ViewModel 上设置 CanEdit 布尔属性的值）。

Answer 4

我个人非常喜欢Play！安全模块可以处理这个问题（教程在这里非常有帮助）。如果您不介意使用 @Before 注释，那么这非常简单。

Answer 5

我现阶段打算按以下方式处理此问题：

• 没有 JS 的表单验证，而是通过 HTTPS ajax

• 一个 Ajax php 类< /p>

• 将表单数据发送到模型作为其具体验证的数据
  常见类型，例如电子邮件和密码（可能关联数组验证将被其他类重用，因此这肯定是一个模型区域）。

• 如果没有错误，则在用户表中查找凭据电子邮件 /
  通过身份验证将密码凭据传递给控制器​​
  键入例如登录/注册/密码重置

• 控制器然后生成所需的输出视图或设置用户登录会话等

这是基于Laravel，但我有自己的库，因为希望它独立于 Laravel，并且只是松散地满足这一重要需求。

要点是模型将所需的凭据作为数据查找，然后发送到控制器，因为它不关心如何处理它。我认为这是使该领域成为每个组件之间明确责任的唯一方法。

Answer 6

根据我个人使用 MVC 框架的经验，我会说：

1. 模型是一个代表数据库表的对象，它应该是
   纯粹的，不应该包含任何额外的逻辑。

2. 控制者是做出决定和其他决定的地方
   自定义逻辑，因此授权应该在控制器中。它
   可以设计一些钩子来检查用户是否被授权
   或者不在所有需要的地方，这样你就不会重复代码。

3. 如果您使用的是典型的，向用户授予权限的最佳方式
   REST架构是制作一个令牌，将其保存在数据库中并在
   客户端并在每个请求上验证此令牌。如果您正在使用
   Web 浏览器应用程序您可以使用服务器端会话进行授权（
   它更容易）。

所以我的建议是将授权逻辑保留在控制器中。

Answer 7

我将使用 Rails 作为示例。授权库 pundit 将授权牢固地置于“模型”域内 - 这是通过其帮助程序强制执行的方法。

假设您有一个 ShoppingBag 模型。您可能想要创建一个 ShoppingBag

class ShoppingBagController
  def create
      authorize ShoppingBag.new, current_user
  end
end

如果您在模型和控制器之间有 1-1 映射，那么它会非常有效。但是，如果您需要同一型号的第二个控制器怎么办？现在你被困住了！

class DiscountedShoppingBagController
  def create
      authorize ShoppingBag.new, current_user # does not work for us. we want a slightly different authorization, on the same model.
  end
end

正是因为这个原因，我不喜欢专家和康康康。对我来说，控制器级别的授权是理想的。在模型级别上这样做对我的限制太大，没有任何相应的增益。