Zend Auth и ACL - PullRequest
       29

Zend Auth и ACL

11 голосов
/ 22 января 2009

Я надеюсь, что некоторые могут помочь мне немного, в настоящее время я разрабатываю свой первый сайт с использованием фреймворка PHP, часть сайта проливается в зону для участников, именно здесь начинает появляться моя путаница с зоной для членов. Я хочу, чтобы обычные участники могли добавлять новые комментарии и редактировать свои собственные комментарии, достаточно просто, чтобы я мог просто сравнить имя автора с именем пользователя, которое хранится в сеансе, моя путаница связана с различием между «обычными» пользователями и пользователи более высокого уровня, которые имеют возможность удалять и изменять любые комментарии и т. д., они также должны иметь доступ к разделу администрирования сайта.

Мой вопрос заключается в том, должны ли все пользователи входить через один и тот же контроллер Zend_Auth, или должны быть отдельные контроллеры, использующие Zend_Auth для каждого типа пользователей, или все это может иметь дело с использованием Zend_Acl? Любая помощь, совет, статья или учебники будут с благодарностью. Лично я думаю, что документация Zend является немного сырой на некоторых классах.

Заранее спасибо

sico87

Ответы [ 4 ]

18 голосов
/ 22 января 2009

Рекомендую книгу «Zend Framework в действии» от Manning Publications как отличное, современное введение в эту тему. Он доступен для скачивания в формате PDF, поэтому вы можете получить его сейчас:)

Но чтобы ответить на этот конкретный вопрос:

Давайте начнем с определения двух ключевых терминов. «Аутентификация» в Zend_Auth относится к аутентификации, которая доказывает, что кто-то является тем, кем, по его словам, он является (то есть логином). «A» в Zend_Acl относится к авторизации, которая доказывает, что кто-то имеет право делать то, что он пытается сделать (то есть контроль доступа).

Предполагая, что пользователь имеет одну роль ... Сохраните роли пользователя в «идентичности», которую вы получаете как часть Zend_Auth. При входе в систему:

$auth = Zend_Auth::getInstance();
$identity = new stdClass();
$identity->user_pk = $user->getPrimaryKey();
$identity->user_name = $user->getName();
$identity->role = $user->getRole(); // select * from user_role where user_pk=xxx
$auth->getStorage()->write($identity);

В контроллере:

$acl->add(new Zend_Acl_Resource('news'))
->allow('defaultRole', 'news');

По умолчанию все запрещено, поэтому вам не нужно указывать:

->deny('defaultRole', 'news', 'add');

Далее в коде контроллера:

$identity = Zend_Auth::getInstance()->getIdentity();
if(!$acl->isAllowed($identity->role, 'news', 'add'))
{
   header('Location: http://www.yoursite.com/error/unauthorized');
}

Если личность пользователя не может делать "новости-> добавить", он будет перенаправлять их на неавторизованную страницу (при условии, что вы создали такую ​​страницу).

Если бы у пользователя было> 1 роль, вы бы сохранили массив ролей в их личности. Тогда ваш чек будет выглядеть примерно так:

$identity = Zend_Auth::getInstance()->getIdentity();
$isAllowed = false;
foreach($identity->role as $role)
{
   if($acl->isAllowed($role, 'news', 'add'))
   {
      $isAllowed = true;
   }
}
if(!$isAllowed)
{  // if NO ROLES have access, redirect to unauthorized page
   header('Location: http://www.yoursite.com/error/unauthorized');
}

Надеюсь, это поможет.

6 голосов
/ 22 января 2009

Да, в большинстве случаев вся ваша аутентификация должна проходить через один и тот же контроллер. Однако Zend Auth не является контроллером. Zend Auth - это API для использования распространенных методов аутентификации, таких как база данных или http. Его работа заключается в том, чтобы быть просто оберткой вокруг тяжелой работы по написанию кода аутентификации.

Zend Acl - это то, что вы ищете, чтобы различать обычных и привилегированных пользователей. Zend Acl включается только после того, как пользователи прошли аутентификацию и вошли в систему.

Большая часть того, что вам нужно, находится в документации ZF. Я прочитал почти всю документацию для Auth и Acl, прежде чем это стало для меня большим смыслом. Хотя ZF Auth, ACL, Storage_ * и другие классы используются очень близко друг к другу, все они служат очень различным целям. Спустя немного времени вы увидите, что они хорошо строятся друг на друге.

Несколько ссылок для начала:

Учебное пособие Падрайка Брейди по ZF

Статья Zend DevZone об ACL и MVC

5 голосов
/ 08 ноября 2009

Я могу понять, почему вы запутались. Я был / все еще немного смущен. Так что, к сожалению, я не могу ответить на ваш вопрос напрямую. Но одна вещь, которую я делаю, чтобы прояснить все эти вещи в моей голове, это думать в терминах «доменных объектов», а не записей базы данных.

Моя тактика для решения этой проблемы - создать мой собственный Аут-адаптер, которому передаются «Базовый объект пользователя» вместе с учетными данными пользователя. Моя «База пользователей» - это своего рода хранилище пользователей.

Таким образом, Zend Auth остается «интерфейсом» для других компонентов Zend, в то время как у меня все еще есть немного больший контроль над моей системой для хранения и доступа к «Пользователям». Мой класс User_Base может быть оберткой вокруг таблицы Zend Db или даже содержать какой-то жесткий код, который я могу использовать для тестирования.

Так в общем -

  • создайте свою собственную модель «пользователя»

  • создайте свой собственный Аут-адаптер - начиная с минимально необходимого интерфейса, как указано здесь: http://framework.zend.com/manual/en/zend.auth.html

  • и просто все упростите и делайте все медленнее, когда вы узнаете больше об этом.

ну вот что я собираюсь делать в любом случае.

Я даже не буду беспокоиться о Zend ACL, но пока у меня в голове нет Auth.


Я обновляю старый сайт и преобразовываю его в Zend MVC

Это некоторые вещи (возможно, нетрадиционные), с которыми мне пришлось столкнуться, чтобы моя «модель» работала. :

  • приложение может использоваться пользователями из нескольких «пользовательских баз» - openID, таблица старых пользователей, таблица новых пользователей, мимолетные гости и т. Д.
  • личность гостя может быть просто хэшем, созданным при первом прибытии
  • тогда как идентификация старого пользователя может быть представлена ​​идентификатором в таблице устаревших пользователей
  • users и user_accounts - это разные вещи. не пытайтесь смешать их в одну концепцию, потому что это может быть сложно.
  • В системе может быть много разных типов учетных записей. То есть Счета покупателей и счета продавцов. Readers_Account vs. Writers_Account
  • учетные записи «имеют» пользователей - «основной владелец учетной записи», «администратор супер пользователь» и т. Д.
  • отношения между пользователями и учетной записью представлены, скажем, «account_users» (локальное подмножество всех пользователей во всех пользовательских базах)
  • роли прикреплены к account_users (пользователям этой конкретной учетной записи). (В отличие от ролей, плавающих вокруг)
  • не бойтесь иметь на сервере более одного приложения Zend для представления веб-сайта - например, приложение администратора, приложение для участников, приложение переднего плана.
  • не бойтесь позволить этим приложениям использовать объекты моделей, хранящиеся, скажем, в папке «общих моделей», с единственным кодом модели, который напрямую связан с отдельным приложением, находящимся в папках / application / models / foomodel.
  • каждое приложение может иметь собственный адаптер Auth
  • Аутентификационный адаптер администратора может разрешать доступ только пользователям из «таблицы пользователей-администраторов», в то время как Аут-адаптер внешнего приложения может проверять подлинность пользователей из гостевой пользовательской базы, персонала или базы пользователей.
  • может быть конкретным случаем, когда сеанс интерфейсных приложений очищается и заменяется сеансом участника при возврате, когда член входит в систему.
  • один пользовательский объект на приложение для каждого веб-клиента в любое время (в отличие от попытки ссылаться на человека с гостевым пользователем И пользователем-пользователем - это слишком сложно)
  • один сеанс на пользователя на приложение (пространство имен, чтобы избежать конфликтов с другими приложениями, в которые они могут войти в этот домен) - (в отличие от попытки одновременно ссылаться на «человека, использующего его» с гостевым сеансом И участником сессия. опять же, это слишком сложно)

хорошо, я начинаю бродить .... но вы поняли идею. Не позволяйте учебникам Zend_Auth + Zend Db, которые вы видите, повлиять на вашу собственную модель. это просто упрощенные примеры.

ничего не сказал

0 голосов
/ 26 февраля 2010

У меня есть несколько вопросов об этом куске кода

    $auth = Zend_Auth::getInstance();
    $identity = new stdClass();
    $identity->user_pk = $user->getPrimaryKey();
    $identity->user_name = $user->getName();
    $identity->role = $user->getRole(); // select * from user_role where user_pk=xxx
    $auth->getStorage()->write($identity);

    $identity = Zend_Auth::getInstance()->getIdentity();

Хранятся ли user_pk, user_name и роль в виде файлов cookie? Будет ли кто-то, кто создает cookie с ролевым именем, иметь доступ к защищенным частям веб-сайтов? Разве пароль (с md5-шифрованием) не должен быть частью идентификации, когда можно проверять имя пользователя и пароль при каждом запросе?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...