Question

在这里进行另一次讨论，讨论如何进行身份验证，或者更有可能。谁应该对用户进行身份验证。

给出以下代码示例：

<?php
class User {
  public function isValid($username, $password) {
      //Logic to check if username/password match
      $this->setId($id);
  }
}

VS

 <?php
 class Auth {
    public function isValid($username, $password) { 
      //Logic to check if username/password match
      $user = new User;
      $user->setId($id);
      return $user;
    }
  }

我个人给出以下示例为什么在这种情况下＃1是坏的：如果允许用户对自己进行身份验证。他们会走进电影院。他们可以走进任何电影。只是对自己说，他们是有效的。

第二个示例的外部对象检查用户的有效性。因此，更多＆＃34; oop＆＃34;

请注意，我没有接受过OOP编程的教育，这可能是我在开始编码时回忆起的事情，但我希望有些人知道我的意思，然后可以解释这里的好/坏做法。

感谢您的进展

Answer 1

逻辑应不在用户身上有两个原因：

它将逻辑与某个后端与用户进行身份验证
该方法对外部参数而不是对象成员进行操作。

现在，可以解析身份验证逻辑（1）并通过执行

class User … 
    public function authenticate(Authenticable $adapter)
    {
        $this->isAuthenticated = $adapter->authenticate(
            array(
                'username' => $this->username,
                'password' => $this->password,
            )
        );
    }
}

但这就是为什么（以及如何）密码应该存储在用户身上的问题。你肯定不想在那里有明文。在我看来，哈希密码不是用户的责任。事实上，如果您不向用户添加盐，则不能在用户中对其进行哈希处理，这是我不会想到的典型用户属性。您可以使用$ adapter中的salt对密码进行哈希处理，但这只是治愈症状。在OOP中，对象方法应该对对象的成员进行操作。但是，如果密码首先不应该是User的成员，那么使用它的方法也不应该在User上（cohesion）。

毋庸置疑，如果您使用的是ActiveRecord，您可能会遇到类似上述的内容，或者将身份验证方法作为静态方法提供给用户，然后返回实例。就个人而言，我不喜欢AR和静态方法，所以我会选择一个单独的Authentication Service类来为我返回用户。

Answer 2

您的User对象将成为用户个人资料的模型，其中包含用户名，密码，电子邮件等详细信息。但是，理论上您可以在网站上拥有个人资料而无需将其链接到登录信息（也许只有一个主管理员可以编辑个人资料。）

您的Auth类将处理登录检查，因为我想这也会处理设置和删除用户会话，这些会话与实际用户配置文件是分开的。

User =用户数据模型
Auth =身份验证逻辑

以这种方式思考，如果您决定更改配置文件身份验证的工作方式（可能会删除您自己的登录流程并将其替换为Twitter OAuth），则将您的身份验证逻辑与用户配置文件分开可以使这更容易。

Answer 3

你是对的，因为一个人在去看电影时认证自己并不常见。在你与同事的争论中，你可能想要概括一下：

谁负责身份验证用户？

这是一个问题，每当你遇到设计问题时，你都可以问自己。我不是说这是一个可以回答你所有问题的规则，但是在很多情况下它清除了困难的视野，你的问题就是一个很好的例子。

您也可以阅读此文：

http://lizkeogh.com/2009/07/01/pixie-driven-development/

谁/什么验证用户PHP OO

3 个答案: