[ZendFramework]Warunkowy ACL, czy ja to dobrze rozumiem Opcje

[mrok]

Pracuję nad systemem do zarządzania firmą, który nie będzie sprzedawany w pudełku, ale każdy chętny będzie sobie mógł założyć konto i w obrębie jego pracować (dostęp przez www).

Implikuje to nałożenie ograniczeń do zasobów, tak aby user z firmy X nie mógł przeglądać dokumentów z firmy Y.

Dotychczas poprzednicy napisali w tym celu sporo metod rozrzuconych po modelach i kontrolerach - ogólnie lekki burdel.

Chciałbym trochę tego posprzątać i tę logikę przenieść do "warunkowych ACLi"

np

[PHP] pobierz, plaintext 
$acl = new Zend_Acl();
$acl->allow('owner', 'document:list', 'show', new CompanyAssertion());
[PHP] pobierz, plaintext 

Czy ktoś podziela taki pomysł (może powinienem zrobić ankietę)? Podobno poprzednicy to byli prawdziwi ninja i zastanawiam się czy przypadkiem nie próbuję wynaleźć koła na nowo.

[Spawnm]

Do tego acl raczej nie będzie potrzebny.
Jeśli wszystko jest oparte o bazę danych to sprawdzaj czy user należy do danej firmy jeśli tak może przeglądać i pobierać dane.
A ACL daj aby ustalić co konkretnie może przeglądać no i czy może dodawać, edytować, kasować.

[mrok]

Jeśli wszystko jest oparte o bazę danych to sprawdzaj czy user należy do danej firmy jeśli tak może przeglądać i pobierać dane.

Oto właśnie chciałem zapytać - gdzie najlepiej to sprawdzić?

Przecież user może sobie spokojnie zmienić w linku
www.blebleble.pl/x/y/z/doc_id/7 na np www.blebleble.pl/x/y/z/doc_id/8

ACL wg Ciebie powinien to puścić ponieważ user ma prawo do przeglądania, edycji, etc. dokumentów

Teraz w modelu dokumentu należałoby dodać jakieś metody które sprawdzają czy user może przeglądać, edytować, usuwać, wysyłać etc.
Mnóstwo sprawdzania zależnego od kontekstu usera, na dodatek trzeba by taką metodę (canEdit, canDelete) wywoływać ręcznie i tu każdy może sie pomylić (albo co gorsza zapomnieć).

Nie ma ciekawszych rozwiązań? Niekoniecznie opartych o ACLe

[destroyerr]

Problem spory i zależy od reszty architektury systemu.
Ogólnie: kontroler powinien zapytać model czy dany użytkownik może wykonać jakąś operację. Więc model powinien mieć interfejs udostępniający możliwość sprawdzenia tego dostępu i to jest chyba jasne. Natomiast najważniejsza kwestia jak model powinien sprawdzać czy jest dostęp. Próbowałem stworzyć podobny system do Twojego (niestety bardziej rozbudowany) i chyba się udało, więc Zend_ACL się nadaje. Ma moim zdaniem jest w nim parę niekonsekwencji (ale to moja interpretacja).
Zdecydowanie dla użytkowników i np. dokumentów nie tworzyłbym tekstowych ról i zasobów tylko skorzystałbym z Zend_Acl_Role_Interface i Zend_Acl_Resource_Interface. Wtedy w CompanyAssertion dostajesz do sprawdzenia obiekt użytkownika i obiekt zasobu dzięki czemu sprawnie możesz pobrać od użytkownika i dokumentu firmę i wtedy porównać. Czyli coś takiego:

[PHP] pobierz, plaintext 
class User implements Zend_Acl_Role_Interface
{
	public function getRoleId()
	{
		return sprintf('user:%s', $this->getId());
	}
}
 
class Document implements Zend_Acl_Resource_Interface
{
	public function getResourceId()
	{
		return sprintf('document:%s', $this->getId());
	}
 
	public function canEdit($user)
	{
		return $this->can($user, 'edit');
	}
 
	public function can($user, $privilege)
	{
		return $this->acl->isAllowed($user, $this, $privilege);
	}
}
 
class CompanyAssertion implements Zend_Acl_Assert_Interface
{
	public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface $role = null, Zend_Acl_Resource_Interface $resource = null, $privilege = null)
	{
		return $role->getCompanyId() == $resource->getCompanyId();
	}
}
[PHP] pobierz, plaintext 

[Deallas]

Tu jest bardzo dobrze wytłumaczone o czym mówił @destroyerr: http://alex-tech-adventures.com/developmen...assertions.html

[mrok]

Ogólnie: kontroler powinien zapytać model czy dany użytkownik może wykonać jakąś operację.

Czyli trochę przez analogię powinienem zapytać miotłę zanim ją użyję czy mogę ja użyć? To nie model miotły ale jakiejś zmutowanej super miotły.

Ja myślałem zrobić to trochę inaczej

[PHP] pobierz, plaintext 
 
 
class DocumentOwnerAsseration implements toCoTrzeba {
 
    private $_request;
 
    public function __construct(Zend_Request_Abstract $request) {
	$this->_request = $request;
    }
 
    public function assert(Zend_Acl $acl, Zend_Acl_Role_Interface $role = null, Zend_Acl_Resource_Interface $resource = null, $privilege = null) {
	$document = Doctrine::getTable('Documents')->find($this->_request->getParam('doc_id'));
	if ($document->Company->isWorker(XX_Auth::getInstance()->getUser()))
	    return true;
 
	// tu jakis ladne info do flash messengera dlaczego cos jest zle
	return false;
    }
 
}
 
class AclPlugin extends Zend_Plugin_Abstract {
 
    public function routeStartup() {
 
	//tutaj cala zabawa z inicjacja acla
	$alc->allow(rola, resource, action, new DocumentOwnerAsseration($this->getRequest()));
 
	if ($alc->isAllow())
	    return true;
 
	throw new Exception();
    }
 
}
 
[PHP] pobierz, plaintext 

Wszystko (nie jest to jakaś strasznie skomplikowana logika) odbywa się w pluginie, żaden controller nie musi być odpalony.
Kwestia roli (księgowa, sprzątaczka, etc) jest zabezpieczona przez regułki ACLa, dodatkowy assert tylko sprawdza czy dokument należy do firmy usera.


//Dellas
Dzięki za linka - trochę podobne do tego co napisałem powyżej.
Tak kilka uwag na szybko.
1. Definicja formularza w zend_form od 1.8 ma być nie w konstruktorze, ale w init()
2. Zend_Auth w metodzie authenticate()
posiada juz kod

[PHP] pobierz, plaintext 
  $this->getStorage()->write($result->getIdentity());
[PHP] pobierz, plaintext 

więc powtarzanie go w AuthenticationControllerze jest niepotrzebne.
3. Nie bardzo rozumiem jak ustawiany jest "$comment" przekazywany do CommentAssertion.php ani Id ani modelu tego obieku w kodzie nie widze ;( Tobie udało sie to rozgryźć?

Ten post edytował mrok 31.10.2010, 20:58:39

[Spawnm]

Tak po najniższej linii oporu można by ten ACL załatwić jednym zapytaniem

query('select * form documents where firma_id = ?', $_SESSION['user_firma_id'] );

I dopiero dla delete czy update sprawdzać w jakiś innych tabelach czy user jest w grupie ADMIN ew. czy w tabeli user_acl ma INSERT_DOC , UPDATE_DOC itd.
Jednak to już bym wyjął po za klasę operacji na tabeli documents.

[murwazy]

dokument jest przypisany do uzutkownika/firmy, przy czytaniu sprawdzasz czy zalogowany chce czytac wlasny dokument, tak samo z kasowaniem itp sprawami.
acla bym w to nie mieszal

[destroyerr]

przy czytaniu sprawdzasz czy zalogowany chce czytac wlasny dokument

Mam wrażenie, że autor wie co ma sprawdzać, a pyta o to "gdzie i jak?".
Ja jednak będę polecał Acl.