PHP

Question

我正在开发具有这种结构的 MVC 应用程序：

   Request
      V
FrontController <-> Router
      V
  Controller <-> Model
      V
     View

我还有两个其他组件需要放入此结构中：

Authentification：使用$_SESSION全局变量登录用户；
RBAC：基于角色的访问控制 可以检查角色是否已授予 "ressource"（Controller 方法）。

每个用户都可以拥有任意数量的角色（他们也可以拥有 none）。

现在，我需要将这两个组件放入我的应用程序中，我需要它们能够：

如果 User 未授权并且 Request 需要执行授权的 User，则应将客户端重定向到登录页面；
如果 RBAC 发现授权的 User 没有被授予所需 "ressource" 访问权限的角色执行 Controller 的方法，Controller 的方法仍应执行，但知道 User 没有执行此操作的权限 (示例：A User 写了一篇文章，但无权发表，所以文章被保存为草稿，User 被告知Moderator 将不得不发布它)。

我已经有了一些关于 Authentification 和 RBAC 位置的想法，但我不确定：

Authentification 可以进入 FrontController 或 Router;
RBAC 可以进入 FrontController 或 Controller.

我看到有人把 RBAC 放在模型中，但我不明白为什么。

我想对这个问题有一些了解。我应该把 Authentification 和 RBAC 组件放在哪里？

谢谢！

Answer 1

在典型的 MVC 应用程序中，身份验证检查（即 "if not auth, then stop and render the login page instead"）在处理请求的早期完成，而业务逻辑（即 "if user has this permission then this happens, otherwise that happens"）在 "C"（控制器）。

大多数框架都有适当的测试机制，例如您描述的身份验证检查 - 名称各不相同，但我经常看到它称为 "middleware"。

基于角色的访问控制完全是您的实现。

Answer 2

根据我的经验，访问控制业务逻辑会随着新功能的添加而发生变化，因此在访问控制系统中设计灵活性和移动性是值得的。因此，我会将身份验证和 RBAC 设计为单独的特征，然后根据需要将这些特征合并到控制器中 space。

如前所述，听起来身份验证特征最好合并到您的前端控制器中：您知道 all 依赖控制器 require身份验证，因此在生命周期的早期合并该检查以释放请求套接字。如果您的要求曾经更改为需要某些控制器被取消门控，您可以将特性向下推送到特定控制器或基本控制器中 class.

至于 RBAC，它可能全局适用于所有控制器，也可能局部适用于某些控制器。例如，您的 FrontController 可能会查询 RBAC 以构建路由 table，而从属控制器将使用 RBAC 来满足其特定需求。

不过要考虑一件事：模型中可能还有一些 RBAC 需求。也就是说，某些角色可能对某些模型中的某些字段具有有限的访问权限：角色 A 可以访问所有模型 X，但角色 B 只能读取模型 X 的字段 1、2、3。（相信我，我见过很多，关于可以查看哪些字段并在哪些字段上执行操作的角色的规则非常复杂。）

将 RBAC 设计为控制器特征可能会使移植到模型 space 变得困难。因此，您可能会发现将 RBAC 设计为服务委托并按需注入会更好。使用配置良好的 IoC 容器，服务委托就像编译时特征一样简单。

最后，我要补充一点，您需要对这两者进行严格测试（毕竟它们很重要）。因此，无论您选择什么，都要进行工程设计，以便对它们进行测试。在我看来，traits 和 delegates 都很容易单独测试，而且两者都是实现必要逻辑的好选择。

PHP - 将 RBAC 和身份验证放在 MVC 应用程序的什么位置？

PHP - Where to put RBAC and Authentification in an MVC application?

authentication

model-view-controller

acl

rbac