Pokročilá architektura oprávnění v Nette

V Nette popsaný přístup může fungovat poměrně elegantně a to i včetně komponent. Tvé požadavky splnitelné jsou – kromě dynamické správy oprávnění (která je nezávislá na zbytku takže ji lze dodělat) to mám i implementované.

Hlavní myšlenky přístupu který používám popsal Oli poměrně dobře. Jen přidám, že naprosto klíčová je zde metoda checkRequirements a je vhodné mít ji povolenou i pro továrničky komponent (což nyní Nette nemá). K tomu několik maker a služba na ověřování + interface přes který je možné definovat pravidla. Díky tomu jsem schopen odebrat z presenteru i anotace s definicí těch pravidel, které jsem tam měl dříve.

Dále bude problém s oprávnění mi typu „redaktor má právo mazat pouze své články“, ale i to mám vyřešené pomocí jisté magie.

Celkově kvůli tomu mám asi 6 extensions, takže to není vůbec easy task, ale šlape to skvěle.

@Tomáš Votruba: Jak víš, původně jsem měl v plánu to vypustit při vydání Nette 2.1 (které nakonec přišlo podstatně dříve než jsem očekával). Jsou tu ale důvody, kvůli kterým jsem to přehodnotil:

• Stálo mě to několik set hodin času, nedokážu odhadnout přesněji.
• Vývoj mi trval něco přes rok (mám k tomu i dokumentaci a testy).
• Poslední nápady které jsem k tomu měl jsem dokončil teprve před několika dny.
• Stále nemám čas nad tím napsat pořádný systém a ani nemám nikoho kdo by to udělal za mne.
• Dá se říct že mi to ještě nevydělalo ani korunu. Jen jsem se při tom naučil spoustu nových věcí a dokázal sám sobě že to zvládnu.

V podstatě nevidím důvod proč to pouštět ven když to sám ještě nevyužívám. Řešení je v podstatě kompletní protože až dnes dokážu říct že mi došly nápady co tam ještě opravit či přidat. Začalo to jako experiment autorizace pomocí anotací, dnes to není omezené ani na autorizaci ani na anotace takže nemyslím že by mi ostatní začali posílat nějaké větší PR s novými funkcemi. Čili, co bych tím získal?

Jsem ochoten se domluvit soukromě, ale prozatím bohužel nemám jiný důvod to zveřejňovat než vrátit komunitě to co mi dala a udělat si jméno. Jméno budu potřebovat až si budu hledat zaměstnání, což zatím není aktuální (navíc stejně dost možná založím vlastní firmu) a přispět vývoji Nette se snažím i tak poměrně často (např. včerejší RFC).

Editoval enumag (10. 2. 2014 15:25)

Niečo podobné som 2× riešil. Prvý krát som zaviedol sadu anotácií pomocou ktorých bolo možné definovať prístupy pre rôzne role a používateľov. Niektoré prípady (napr. mazanie vlastných článkov) boli veľmi zložito a neintuitívne riešiteľné.

V ďalšom projekte na to šiel trochu inak. Definoval som zoznam zdrojov a subjektov.

Zdroje obsahovali presenter a akciu, prípadne ešte jemnejšie delenie. Ak končil názov oprávnenia na pomlčku, tak sa bral do úvahy aj identifikátor. Tzn. zdrojom article sa dalo povoliť/zakázať prístup k celému presentru article, ale napríklad zdroj article-delete- (pomlčka na konci) sa dalo nastaviť oprávnenie na zmazanie konkrétneho článku. ID článku sa k oprávneniu v prípade potreby prilepilo. V konfigurácií stačilo nastaviť, že v prípade ak začína názov oprávnenia na article, tak sa berie do úvahy napr. identifikátor article.id_article.

Subjekty boli používatelia alebo role ktorých oprávnenie bolo nastavované + ich identifikátor.

Vo výsledku je takto možné hierarchicky nastaviť oprávnenie na ľubovoľnú akciu pre ktoréhokoľvek používateľa/rolu.

Do odkazov som pridával n:if="$acl->isAllowed("article", "article-delete", "artice-delete-$id)". Obdobne funguje overovanie v ľubovoľnej metóde. isAllowed vracia boolean a checkRequirements v prípade FALSE presmeruje na prihlásenie alebo vyhodí výnimku.

Ako najvhodnejší postup overovanie práv mi nakoniec vyšiel postup:

• Ak nie je nastavené oprávnenie na žiadny zo zdrojov (v kombinácií s aktuálnou rolou a používateľom) tak je je výsledkom FALSE (predvolene).
• Ak je niektoré oprávnenie TRUE, stále ho môže prepísať FALSE.
• Oprávnenie používateľa má prednosť pred oprávnením skupiny.

K tomuto postačí jednoduchá tabuľka resource, resource_id, subject, subject_id a access (TRUE/FALSE).

Na automatizované pridávanie/odoberanie práv v prípade nejakých akcií, zmien stavov a pod. sa mi osvedčilo zavesenie na udalosti pomocou Kdyby/Events. V ideálnom prípade by bola štruktúra tabuľky so zoznamom oprávnení premakanejšia a cez triggre a cudzie kľúče by sa automaticky mazali nepotrebné pravidlá, ale k tomu nebol čas.

Ako GUI postačil obyčajný GRID.

@enumag: já jsem skromný: mě stačí, že řešení existuje, takže snaha o vytvoření vlastního řešení není předem odsouzená k záhubě :D

Hurá do práce! :p