Автор зенда и ACL

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

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

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

Несколько ссылок для запущения Вас:

Учебное руководство ZF Pádraic Brady

Статья DevZone зенда о ACL и MVC

Я рекомендую книгу "Платформа зенда в Действии" от Укомплектования людьми Публикаций как великое, актуальное, введение в это. Это доступно как загрузка 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');
}

Надежда, которая помогает.

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

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

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

Итак, в общем -

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

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

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

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

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

Я переделываю наследие site и преобразование его в Zend MVC

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

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

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

Нафф сказал

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

Нафф сказал

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

Нафф сказал

Краткий ответ: для PUT и DELETE необходимо отправить либо 200 (OK), либо 204 (No Content).

Длинный ответ: вот полная схема решения (нажмите, чтобы увеличить).

Источник: https ://github.com/for-GET/http-decision-scheme

Единственное практическое применение минимальной высоты - приклеивание нижнего колонтитула к нижней части страницы. Обратите внимание на следующий код:

<html>
  <head></head>
  <body style="height: 100%">
    <div style="height: 100%">
      <div style="height: auto; min-height: 100%; background-color: blue;">
        <div class="main" style="padding-bottom: 300px;">
        </div>
      </div>
      <div class="footer" style="height: 300px; background-color: red; margin-top: -300px;"></div>
    </div>
  </body>
</html>

Красный цвет прилипает к нижней части порта просмотра, когда основной div пуст, а при заполнении основного div содержимым красный нижний колонтитул по-прежнему прилипает к нижней части страницы.

Чтобы проиллюстрировать точку, если вы просто используете высоту: 100% на главном погружении и заполняете его содержимым, красный нижний колонтитул будет наведен в нижней части видового экрана. Высота, указанная как 100%, не расширяет основное сечение за пределы видового экрана, как это будет при объявлении высоты: auto; минимальная высота: 100%.

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

    $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-шифрованием) быть частью идентификатора, чтобы когда можно было проверить имя пользователя и пароль при каждом запросе?