2011-12-17 3 views
1

Мне нужно решение, в котором аутентифицированным пользователям разрешен доступ к определенным контроллерам/действиям, основанным не на их пользовательском типе: т.е. admin или обычный пользователь (хотя я могу добавить это, используя стандартный ACL позже), но в соответствии с текущим статусом своего пользователя.Динамический пользовательский ACL в zend framework?

Например:

ли они членом сайта более чем на 1 неделю?

Полностью ли они заполнены в своем профиле?

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

ответ

1

Для динамических тестов на основе условий, которые вы описываете, вы можете использовать dynamic assertions в своих правилах Zend_Acl.

Например:

class My_Acl_IsProfileComplete implements Zend_Acl_Assert_Interface 
{ 
    protected $user; 

    public function __construct($user) 
    { 
     $this->user = $user; 
    } 

    public function assert(Zend_Acl $acl, 
          Zend_Acl_Role_Interface $role = null, 
          Zend_Acl_Resource_Interface $resource = null, 
          $privilege = null) 
    { 
     // check the user's profile 
     if (null === $this->user){ 
      return false; 
     } 
     return $this->user->isProfileComplete(); // for example 
    } 
} 

Тогда при определении вашего объекта Acl:

$user = Zend_Auth::getInstance()->getIdentity(); 
$assertion = new My_Acl_Assertion_IsProfileComplete($user); 
$acl->allow($role, $resource, $privilege, $assertion); 

Конечно, некоторые детали зависят от специфики того, что вы должны проверить и то, что вы можете использовать в зависимости от того, что вы храните в своем Zend_Auth::setIdentity() вызове - только идентификатор пользователя, полный пользовательский объект и т. д. И роли, ресурсы и привилегии полностью зависят от приложения. Но, надеюсь, это дает идею.

Кроме того, поскольку объект утверждения требует объекта-пользователя при создании экземпляра, это динамическое правило не может быть добавлено в Bootstrap. Но вы можете создать основной экземпляр Acl со статическими правилами во время начальной загрузки, а затем зарегистрировать плагин переднего контроллера (для запуска в preDispatch(), скажем), который добавляет динамическое утверждение. Таким образом, Acl полностью заполняется к тому времени, когда вы дойдете до контроллеров, где, предположительно, вы будете их проверять.

Просто думая вслух.

+0

Привет - просто интересно, если вы когда-либо видели/использовали динамические утверждения, созданные из ролевых условий? Например, в вопросе OP '' член сайта более 1 недели '' может быть 'членом сайта более $ n недель (-ов)", где '$ n' отличается для каждой роли , поэтому администратор будет иметь доступ на '$ n> = 0' недель, модератор может быть' $ n> = 1', а фактический член может быть '$ n> = 4' ... – boatingcow

+0

Я никогда не видел это интересный вопрос. Но кажется, что такие правила могут быть кодифицированы как массивы с ключевыми именами с числом недель, требуемых для того, чтобы считаться «достаточно длинными». Этот массив можно было бы включить в динамическое утверждение, возможно, как необязательный аргумент конструктора (со стандартными значениями по умолчанию). Затем, когда метод assert() 'динамического утверждения в конечном итоге вызывается, он имеет правила на основе ролей (от экземпляра) и рассматриваемой роли (как часть' assert () 'signature), которого должно быть достаточно. –

+0

Это то, о чем я думал. Я задал вопрос некоторое время назад http://stackoverflow.com/quest ion/7526855/how-to-codify-and-store-dynamic-permission-constraints, но на самом деле не получилось. Было бы неплохо найти больше ресурсов на этом типе вещей! – boatingcow

Смежные вопросы