Acl pomocou anotaci na presenter, action a handle

duskohu

Caute, Chcel by som si rozchodit ACL pomocou anotaci tak ze ked sa bude volat presenter, action, handle, tak to najprv bude ovarovat opravnenie uzivatela na zaklade anotacie, role, ci uz v presentru alebo komponente. Samozrjme planujem nejako vyriesit aj overovanie vlastnictva polozky v db, napr. clanku. Nevedeli by ste ma niekto nakopnut akym sperom sa vydat a realizovat to?

romiix.org

Tento problém som už riešil. Dostal som sa k jednej metóde v BasePresenter ktorá pri každej požiadavke kontrolovala či má používateľ k presentru, akcií alebo signálu prístup cez anotáciu. V anotácií sa nachádzal zoznam rôl ktoré majú prístup.
Napr.:

/** @access (customer,admin)*/

Zároveň sa oprávnenia dedili – stačilo zabezpečiť presenter a automaticky boli zabezpečené aj metódy. S týmto som bol vcelku spokojný v danom projekte.

Teraz som nútený naprogramovať niečo komplexnejšie, pretože v prípade anotácií nie je možné bez zásahu do zdrojákov meniť práva. Taktiež nie je jednoducho riešiteľné oprávnenie na úrovni konkrétneho používateľa (nie skupiny) a oprávnenie vlastníka.
Plánujem teda nasadiť anotácie popisujúce názov zdroja (presenter,view,hendle) ktoré sa použijú pre GUI. Základné nastavenie previesť v neon konfigurácií a následne ich prepisovať nastaveniami z DB. Toto kešovať a hotovo:)

Každopádne je potrebné vopred si premyslieť čo všetko potrebuješ zabezpečiť a s akým rozlíšením.

duskohu

Zatial som urobil zaklad, Len tu nastal problem, guest > loggedIn > manager > bigBoss, ako nastavim dedicnost roli? Ked sa prihlasim ako bigBoss tak by som mal mat pristup k handle, ale realne tu rolu medi rolami nemam, kedze by som to mal nejako dedit.

/**
 * @Secured
 * @User(loggedIn, role=manager)
 */
public function handleTest() {

}

public function checkRequirements($element) {
    if ($element->hasAnnotation('Secured')) {
        $user = $this->getUser();
        $userAnnotation = (array) $element->getAnnotation('User');

        if (in_array('loggedIn', $userAnnotation) && !$user->isLoggedIn()) {
            throw new ForbiddenRequestException('You do not have permission to view this page.');
        }
        if (array_key_exists('role', $userAnnotation) && !in_array($userAnnotation['role'], $user->getRoles())) {
            throw new ForbiddenRequestException('You do not have permission to view this page.');
        }
    }
}

Šaman

Dělal jsem si něco podobného, ale nakonec jsem to zrušil. Nebylo to dostatečně pružné (Mazat může jen admin je v pohodě. Ale mazat může ten, kdo příspěvek vložil, to už asi nezapíšeš.) a za chvíli jsem se na to zabezpečení začal spoléhat, i když bylo spíš pracovní.
Navíc každý presenter bylo stejně nutné zapsat do ACL, tak nakonec jsem převedl i pravidla zpátky pod ACL.
Myslím že v tom projektu jsem nakonec nechal jen anotaci @secured, která zajistila, že se ve stratupu kontrolovala práva na aktuální action. Ale pravidla už byla všechna v ACL. Další výhoda je, že máš všechna pravidla pohromadě a ne rozházená po presenterech.

duskohu

Hmmm, takze odporucate pouzivat ACL ale ako resource a privilege pouzivat anotacie, nie $this->name ?

/**
    * @Secured
    * @Resource("Homepage")
    * @Privilege("Show")
    */

Šaman

To ne, resource a privilege jsem načítal automaticky jako název presenteru a akce.
Ale teď jsem na to koukal a vlastně jsem to zavrhl úplně, protože pořád není možné předat třeba id mazaného záznamu, tedy otestovat zda uživatel může smazat tenhle konkrétní záznam. Id se dá sice vytáhnout z requestu, ale je to naslepo, občas předávám dvě Id (třeba id tagu které se má smazat z id knihy) a tam už si s tím nějaká obecná logika ve strartupu neporadí. Takže používám tradiční ověřování pomocí ACL až v konkrétních akcích, které se umějí zeptat přesně na to, co potřebuji.

Přemýšlel jsem jestli teda nemít kontrolu nahrubo (nepřihlášený uživatel nesmí nikam jinam než na přihlášení) a zbytek řešit v jednotlivých akcích, ale přišlo mi to zbytečný. ACLku se nevyhnu a akorát budou práva na několika místech a ne pohromadě.

Editoval Šaman (19. 3. 2013 18:50)

enumag

Tohle je další z těch věcí co už mám vyřešené (ano, včetně oprávnění k určitému záznamu) akorát jsem to ještě nestihl pořádně ani sám použít, natož abych to zveřejnil jako addon. :-(