Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [ZendFramework]Kontrola dostępu
Forum PHP.pl > Forum > PHP > Frameworki
juzwa
jak rozumiem to idea Zend_Acl opiera się na takich zasadach

1)zdefiniowanie, stworzenie ról - niech będzie to
-administrator
-zlecacz
-kontroler
-instalator

  1. <?php
  2. $acl = new Zend_Acl();
  3.             $acl->addRole(new Zend_Acl_Role('admin'))
  4.                ->addRole(new Zend_Acl_Role('kontroler'))
  5.                ->addRole(new Zend_Acl_Role('zlecacz'))
  6.                ->addRole(new Zend_Acl_Role('instalator'));
  7. ?>



2)na podstawie parametru z bazy danych przypisuje się aktualnie zalogowanego użytkownika do jakieś roli

3)zależy jak to ma zdefiniowane kontrolery tak sobie przypisuje uprawnienia, ja mam na zasadzie "obiektów" np uzytkownik, plik, zlecenie itp - do każdej akcji z tych obiektów dana rola ma lub nie ma dostępu - np do edycji swoich danych (z kontrolera użytkownik) ma dostepk każdy, a do dodawanie np tylko admin itp itd,
no to sobie trzeba zdefiniować zasoby - tyle ile trzeba dla uzytkowników

  1. <?php
  2. $acl->add(new Zend_Acl_Resource('user/add'));
  3. $acl->add(new Zend_Acl_Resource('user/edit'))
  4. ?>


4) i potem sprawdza się czy ma sie dostęp
  1. <?php
  2. $controler     = $this->_request->getControllerName();
  3. $action     = $this->_request->getActionName();
  4. if(!$acl->isAllowed($rola ', $controler.'/'.$action))
  5. $this->_redirect('auth/error403);
  6. ?>


ale jaka z tego jest korzyść skoro mozna sobie XML-a zrobić
  1. <acl>
  2.    <!--role-->
  3.    <admin>
  4.         <!--kontrolery-->
  5.         <controler name="user">
  6.               <!--akcje-->
  7.               <action>add</action>
  8.               <action>edit</action>
  9.         </controler >
  10.    </admin>
  11. </acl>


i potem za pomocą parsera to sobie sprawdzić?

może coś źle mówię, nie wiem, ale wydaje mi się, że taki sposób z XML-em jest szybszy do napisania i wygodniejszy

ps - jeśli coś źle napisałem o zasadach tworzenia kontroli dostępu i samej kontroli Zend_Acl to prosze o wyprowadzenie mnie z błędu
kosmowariat
Po pierwsze, nigdzie nie widzę przypisania ról do zasobów. Po drugie dodawanie zasobów z poziomu PHP w przypadku XML'a nie będzie sprawą najłatwiejszą, a chyba chciałbyś żeby admin mógł nadawac prawa z poziomu panelu admina ? Oczywiście można wykorzstac XML'a ale to do mnie nie przemawia. DB + cacheowanie i jest gitara. W momencie gdy będziesz miał dużo resource'ów i kilka ról sam stwierdzisz że XML to nie jest najlepszy pomysł ;-) Taka jest moja opinia
chlebik
Potwierdzę fakt, że trzymanie CZEGOKOLWIEK na XMLu, co nie jest transportem informacji między 2 systemami, albo skromniutkim plikiem konfiguracyjnym jest GRZECHEM SMIERTELNYM. I mowie to na bazie swojego doswiadczenia - ACL najlepiej jest implementowac na bazie z cache (jak napisal moj przedpisca), jedyna rzecz, ktora jest tutaj dyskusyjna to skalowalnosc uzytego rozwiazania - czy beda to raptem 3 czy 5 tabel. Z definicji bowiem jest tak, ze na poczatku wystacza nawet wpisanie rol i zasobow na sztywno w pliku, a po kilku miesiacach i zmianach koncepcji w aplikacji robi sie taki balagan, ze rzecz trzeba przepisywac od nowa.

Polecam ten artykul - zasadniczo cos takiego wlasnie wcielam w zycie w aplikacji.
konys
Ja się pozwolę wciąć w wątek z zapytaniem o to jakie tworzycie przywileje.
Przykład: forum - admin może moderować dowolny post, użytkownik jedynie swoje. W zasadzie edycja przez admina i edycja przez użytkownika to ta sama operacja więc wystarczyłoby nadać jeden przywilej (edycji), przy czym zasobami admina byłyby wszystkie posty, zaś użytkownika - jedynie własne. Drugie rozwiązanie to nadanie adminowi uprawnień do edycji a użytkownikowi stworzenie czegoś na kształt przywileju editOwn - edycji tylko własnych postów. Przyznam, że to rozwiązanie do mnie raczej nie przemawia ze względu na dość ścisłe powiązanie ACL z resztą kodu (przy pierwszym rozwiązaniu mamy jedynie funkcjonalność edycji pojedynczego postu, przy drugim musimy obsłużyć dodatkowo edycję postów danego użytkownika). Chętnie jednak poznam wasze opinie.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.