[ZendFramework] Zend_Acl, Jak odczytać uprawnienia w widoku? Opcje

[nexis]

W jaki sposób mogę w widoku (np. views/scripts/index/index.phtml) uzyskać informację czy zalogowany użytkownik ma dostęp do jakiegoś działu? Chciałbym to uzyskać za pomocą funkcji typu isAllowed('controller', 'action') abym mógł ukryć linki w menu, do których użytkownik tak czy inaczej nie ma dostępu. Zend_Acl skonfigurowałem w następujący sposób:

bootstrap.php

[PHP] pobierz, plaintext 
<?php
defined('APPLICATION_PATH')
   or define('APPLICATION_PATH', dirname(__FILE__));
 
defined('APPLICATION_ENVIRONMENT')
    or define('APPLICATION_ENVIRONMENT', 'development');
 
$frontController = Zend_Controller_Front::getInstance();
$frontController->setControllerDirectory(APPLICATION_PATH . '/controllers');
$frontController->setParam('env', APPLICATION_ENVIRONMENT);
 
Zend_Layout::startMvc(APPLICATION_PATH . '/layouts/scripts');
$view = Zend_Layout::getMvcInstance()->getView();
$view->doctype('XHTML1_STRICT');
 
$configuration = new Zend_Config_Ini(APPLICATION_PATH . '/config/app.ini', APPLICATION_ENVIRONMENT);
 
$dbAdapter = Zend_Db::factory($configuration->database);
$dbAdapter->query('SET NAMES utf8');
Zend_Db_Table_Abstract::setDefaultAdapter($dbAdapter);
 
$registry = Zend_Registry::getInstance();
$registry->configuration = $configuration;
$registry->dbAdapter     = $dbAdapter;
 
require_once APPLICATION_PATH . '/models/Acl.php';
require_once APPLICATION_PATH . '/models/Auth.php';
$auth = Zend_Auth::getInstance();
$acl  = new Acl($auth);
$frontController->registerPlugin(new Auth($auth, $acl))
                ->setParam('auth', $auth);
 
 
unset($frontController, $view, $configuration, $dbAdapter, $registry);
?>
[PHP] pobierz, plaintext 

models/Auth.php

[PHP] pobierz, plaintext 
<?php
class Auth extends Zend_Controller_Plugin_Abstract
{
   public $_auth;
   public $_acl;
   
   private $_noauth = array('module' => 'default', 'controller' => 'user', 'action' => 'login');
   private $_noacl  = array('module' => 'default', 'controller' => 'user', 'action' => 'noAccess');
   
   public function __construct($auth, $acl)
   {
      $this->_auth = $auth;
      $this->_acl  = $acl;
   }
   public function preDispatch(Zend_Controller_Request_Abstract $request)
   {
      $role = ($this->_auth->hasIdentity()) ? $this->_auth->getStorage()->read()->role : 'guest';
   
      $controller = $request->controller;
      $action     = $request->action;
      $module     = $request->module;
      $resource   = $controller;
   
      if (!$this->_acl->has($resource)) {
         $resource = null;
      }
   
      if (!$this->_acl->isAllowed($role, $resource, $action)) {
         if (!$this->_auth->hasIdentity()) {
            $module     = $this->_noauth['module'];
            $controller = $this->_noauth['controller'];
            $action     = $this->_noauth['action'];
         } else {
            $module     = $this->_noacl['module'];
            $controller = $this->_noacl['controller'];
            $action     = $this->_noacl['action'];
         }
      }
         
      $request->setModuleName($module);
      $request->setControllerName($controller);
      $request->setActionName($action);
   }
}
?>
[PHP] pobierz, plaintext 

models/Acl.php

[PHP] pobierz, plaintext 
<?php
class Acl extends Zend_Acl
{
   public function __construct(Zend_Auth $auth)
   {      
      $this->add(new Zend_Acl_Resource('category'));
      $this->add(new Zend_Acl_Resource('error'));
      $this->add(new Zend_Acl_Resource('index'));
      $this->add(new Zend_Acl_Resource('localization'));
      $this->add(new Zend_Acl_Resource('object'));
      $this->add(new Zend_Acl_Resource('objectcategory'));
      $this->add(new Zend_Acl_Resource('objectelement'));
      $this->add(new Zend_Acl_Resource('objectphoto'));
      $this->add(new Zend_Acl_Resource('pattern'));
      $this->add(new Zend_Acl_Resource('patternelement'));
      $this->add(new Zend_Acl_Resource('postcode'));
      $this->add(new Zend_Acl_Resource('user'));
      
      # Guest
      $this->addRole(new Zend_Acl_Role('guest'));
      $this->allow('guest', 'index');
      $this->allow('guest', 'error');
      $this->allow('guest', 'user');
      
      # Editor
      $this->addRole(new Zend_Acl_Role('editor'), 'guest');
      $this->allow('editor', 'localization');
      $this->allow('editor', 'object');
      $this->allow('editor', 'objectcategory');
      $this->allow('editor', 'objectelement');
      $this->allow('editor', 'objectphoto');
      $this->allow('editor', 'postcode');
      
      # Manager
      $this->addRole(new Zend_Acl_Role('manager'), 'editor');
      $this->allow('manager', 'category');
      $this->deny('manager', 'object', 'activate');
      $this->allow('manager', 'pattern');
      $this->allow('manager', 'patternelement');
      
      # Administrator
      $this->addRole(new Zend_Acl_Role('administrator'));
      $this->allow('administrator'); 
   }
}
?>
[PHP] pobierz, plaintext 

Ten post edytował nexis 15.01.2009, 23:06:41

[qba_rox]

utworz sobie view helper, ktory renderuje ci menu i w nim pobierz z rejestru obiekt acl i sprawdzaj dostep do danego linku. chyba o to chodzi? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

jest pozno i tak sobie wymyslilem: (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[PHP] pobierz, plaintext 
<?php
class Your_View_Helper_RenderMenu {
 
    public function RenderMenu() {
        
        $acl = Zend_Registry::get('acl');
                $role = Your_Auth->getInstance()->getRole();
 
                if($acl->isAllowed($role, 'menu1', 'display')){ 
                   $menu .= '<a>menu1</a>';
                }
    }
//...
 
}
?>
[PHP] pobierz, plaintext 

o to chodzilo? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[batman]

A ja dodam od siebie, że ten helper powinien rozszerzać helper url i zwracać albo pusty ciąg (jeśli użytkownik nie ma uprawnień) lub to co zwraca helper url (jeśli użytkownik posiada uprawnienia).

[LBO]

A ja dodam od siebie, że ten helper powinien rozszerzać helper url i zwracać albo pusty ciąg (jeśli użytkownik nie ma uprawnień) lub to co zwraca helper url (jeśli użytkownik posiada uprawnienia).

Nie zgodzę sie z Tobą - to niepotrzebne mieszanie odpowiedzialności. Spójrz na poniższe podejście:

[PHP] pobierz, plaintext 
<?php if($this->acl()->isAllowed($this->auth()->getRole(), 'menu1', 'display')) : ?>
<div><?php print $this->menu(); ?></div>
<?php else : ?>
<div>menu niedostępne</div>
<?php endif; ?>
[PHP] pobierz, plaintext 

Posiadasz większą kontrolę. Dodatkowo przy tym sposobie nie musisz się ograniczać do menu, ale także do pojedynczych linków tj. "edytuj", "usuń"; które prowadza do akcji wymagających pewnych uprawnień.

Ważne, żeby posiadać helpery wykonujące jak najbardziej "atomowy" kod. Dzięki temu możesz tworzyć i proste jak i bardzo skomplikowane struktury.

[batman]

Nie zgodzę sie z Tobą - to niepotrzebne mieszanie odpowiedzialności. Spójrz na poniższe podejście:

Dlaczego?
Jeśli chcesz zrobić link, który ma się wyświetlać tylko dla konkretnej grupy użytkowników nie musisz kombinować z if-ami, które zaciemniają kod. Po prostu używasz helpera i nie martwisz się o to, czy dany element menu ma się pokazać, czy nie. A jeśli nie chcesz rozszerzać helpera url, to możesz po prostu go zastosować wewnątrz swojego helpera.

[LBO]

Przesadzasz z tymi ifami to właśnie bez Nich jest mniej czytelnie.

[PHP] pobierz, plaintext 
<?php
$this->menu();
?>
[PHP] pobierz, plaintext 

To mi nic nie mówi. Czy się będzie wyświetlać i kiedy.

[batman]

To dodaj do przykładu jeszcze z 10 linków i każdy trzymaj w takim if-ie. Od razu można się pogubić. Poza tym wszystkie zmiany w uprawnieniach powodują, że trzeba w każdym if-ie zmieniać warunek. A tak, wystarczy zmienić to w jednym miejscu - w helperze.

[LBO]

Linki linkami. Natomiast taki sposób jaki ty podajesz powoduje, że przeładowujesz helper funkcjonalnością - menu() wyświetla menu i tyle. Ty chcesz jeszcze wpakować odpowiedzialność czy w ogóle ma je wyświetlać.

Nie twierdzę, że mam robić drzewko ifów tylko, że w budowie samych helperów trzeba zachować umiar. ot co.

[batman]

Nie do końca pisaliśmy o tym samym. Ty pisałeś o całym menu, a ja o konkretnych linkach. Dlatego nie możemy dojść do porozumienia. Jeśli autor stworzy helper, który wyświetli lub nie (w zależności od uprawnień) elementy menu (linki), wówczas osiągnie to o co mu chodziło.

[LBO]

Zawsze są jeszcze partiale. Nie wymagają dodatkowego helpera i posiadają korzyści płynące z mojego sposobu.

[qba_rox]

Rozbijanie problemu wyswietlania linkow, na pojedyncze helpery nie ma zadnego sensu, bo jest to nie wydajne (zobacz ile obiektow musisz powolac i wykonywac wielokrotnie czynnosci ktore mozna zrobic raz) i robi bajzel w pliku widoku.
uwazam tak jak LBO, ze $this->renderMenu() jest duzo lepszym sposobem. Choc wcale nie zgodze sie z tym, ze sprawdzamy dostep tylko do calego menu.

Poza tym wszystkie zmiany w uprawnieniach powodują, że trzeba w każdym if-ie zmieniać warunek. A tak, wystarczy zmienić to w jednym miejscu - w helperze.

nie prawda:

[PHP] pobierz, plaintext 
<?php
$menu['add'] = 'Dodaj';
$menu['edit'] = 'Edytuj';
$menu['delete'] = 'Usun';
 
//lub $menu = $model->getMenu();
$menu = '';
foreach($menu as $key=>$entry){
  if($acl->isAllowed($role, "mainMenu:$key", 'display'))
    $menu .= "<a>$entry</a>" . PHP_EOL;
 
}
 
return $menu;
?>
[PHP] pobierz, plaintext 

gdzie sa ify? bo ja ich nie widze (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) i mamy tylko jedna instrukcje sprawdzania uprawnien (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[batman]

No tak, ale cały czas kręcimy się w obrębie menu. A co jeśli trzeba stworzyć osobne linki, np edycja. Wówczas dla każdego linka trzeba będzie tworzyć helper. A o wydajność się nie martwię z dwóch powodów.
1. Jeśli stawiam aplikację na ZF, to jest to aplikacja kombajn, a nie wizytówka.
2. Wszystko co tylko można jest cache-owane.

[qba_rox]

Hehe, mysle ze koles co zalozyl temat, ma juz odpowiedz (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)
masz racje, czasem warto poswiecic wydajnosc na rzecz lepszej swobody w programowaniu skoro i tak to cachujemy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) uwazam ze twoje podejscie jest bardzo dobre jesli chodzi o o pojedyncze linki, ale uwazam ze moje jest lepsze jesli mowimy o zbiorze linkow luzno powiazanych z soba (np menu). Co szkodzi nam miec 2 helpery, do pojedynczow liknkow jak i do ich grupy? (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[LBO]

Nie narzekajcie z tymi obiektami helperów, bo te są tworzone tylko raz (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Przynajmniej byływ czasach ~1.0 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Poprawcie mnie jeżeli się mylę, bo do ZF dawno nie zaglądałem.

[batman]

Dokładnie o to mi chodziło. Nie ma przecież obowiązku korzystać za każdym razem z helpera, który sprawdza prawa dostępu. Przecież nie każdy link prowadzi do strony z ograniczeniami.
Poza tym jeśli chodziłoby o menu, to też bym zrobił osobny helper do tego.


Zapomniałem dodać po pierwszego punktu w poprzednim moim poście, że taka aplikacja stoi na potężnej maszynie, której nie straszny jest ZF (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)


edit up
Tak. Obiekt helpera jest tworzony tylko raz.

[qba_rox]

to prawda raz, ale nie chodzilo mi tu akurat o same obiekty helperow, tylko obiekty wewnatrz helpera, np obiekt modelu, konfiguracji (oczywiscie moze nie byc zadnych obiektow), poza tym odwolywanie sie dziesiatki razy do helpera nie jest wydajne, po to ludzie robia cos takiego.

Ten post edytował qba_rox 16.01.2009, 12:53:44