Zend Auth и ACL

Ответ 1

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

Но для ответа на этот конкретный вопрос:

Давайте начнем с определения двух ключевых терминов. "Auth" в 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');
}

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

Если у пользователя была роль > 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');
}

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

Ответ 2

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

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

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

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

Pádraic Brady ZF Tutorial

Статья Zend DevZone в ACL и MVC

Ответ 3

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

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

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

Итак, вообще говоря -

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

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

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

Хорошо, что я все равно сделаю.

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

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

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

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

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

nuff сказал

Ответ 4

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

    $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, имя_пользователя и роль хранятся как файлы cookie? Будет ли кто-то, кто делает cookie с именем роли, доступным для защищенных частей веб-сайтов? Должен ли пароль (с md5-encryption) быть частью идентификатора, а также, когда вы можете проверить имя пользователя и пароль с каждым запросом?