Кто / что аутентифицирует пользователя PHP OO

Question

попал в другую дискуссию на работе здесь о том, как проходить аутентификацию, или, что более вероятно. Кто должен аутентифицировать пользователя.

Приведены следующие примеры кода:

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

против

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

Я лично привожу следующий пример, почему в этом случае # 1 плохо: Если пользователю разрешено аутентифицировать себя. И они шли в кинотеатр. Они могут просто войти в любой фильм. Просто говорю себе, что они действительны.

Где во втором примере есть внешний объект, проверяющий достоверность пользователя. Таким образом, будучи более "упс"

Имейте в виду, у меня нет образования в программировании ООП, и это, вероятно, то, что я прочитал еще в '08 или '09, когда я начал кодировать :) Я надеюсь, что некоторые люди здесь знают, что я имею в виду, и затем могут объяснить, что хорошо / плохие практики здесь.

Спасибо, в процессе

Answer 1

Логика должна не находиться на Пользователе по двум причинам:

1. она связывает логику для аутентификации с определенным бэкэндом для пользователя
2. Метод работает с внешними аргументами вместо членов объекта.

Теперь вы можете отделить логику аутентификации (1) и работать с членами объекта (2), выполнив

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

но возникает вопрос, почему (и как) пароль вообще должен храниться на Пользователе.Вы, конечно, не хотите иметь открытый текст там.И хеширование пароля, по моему мнению, не является обязанностью Пользователя.На самом деле, вы не можете хэшировать его в User, если вы не добавляете соль пользователю, и я бы не подумал о типичном свойстве User.Вы можете хэшировать пароль, чтобы перефразировать его солью в $ адаптере, но это только излечивает симптомы.В ООП методы объекта должны работать с членами объекта.Но если пароль, в первую очередь, не должен быть членом Пользователя, метод, использующий его, также не должен использоваться для Пользователя ( cohesion ).

Само собой разумеется, если вы используетеActiveRecord, у вас, скорее всего, будет что-то подобное выше, или у вас будет метод аутентификации в качестве статического метода для пользователя, который затем вернет экземпляр.Лично мне не нравятся AR и статические методы, поэтому я бы пошел с отдельным классом службы аутентификации, который возвращает пользователей для меня.

Answer 2

Ваш User объект будет моделью для профиля пользователя, содержащей такие данные, как имя пользователя, пароль, адрес электронной почты и т. Д. Однако теоретически вы можете иметь профиль на сайте, не связывая его с логином (возможно, существуеттолько один главный администратор, который может редактировать профили).

Ваш класс Auth будет обрабатывать проверку входа в систему, поскольку, как я полагаю, это также касается настройки и удаления пользовательских сеансов, которые отделены от фактического профиля пользователя.

• User = Модель для пользовательских данных
• Auth = Логика для аутентификации

Подумайте об этом, если вы решили изменить способАутентификация вашего профиля работает (возможно, удалив ваш собственный процесс входа в систему и заменив его на Twitter OAuth), отделив вашу логику аутентификации от вашего профиля пользователя, это может упростить эту задачу.

Answer 3

Вы правы в том, что человек не очень часто идентифицирует себя, например, при посещении фильма.В споре с коллегами вы можете обобщить следующее:

Кто отвечает за аутентификацию пользователя?

Это вопрос, который вы можете задатьсебя каждый раз, когда вы, кажется, застряли на вопрос дизайна.Я не говорю, что это единственное правило, которое ответит на все ваши вопросы, но во многих ситуациях оно помогает устранить проблемы со зрением, и ваш вопрос является отличным примером.

Вы также можете прочитать этот текст:

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