Dynamická ACL a návrh vhodné DB struktury pro CMS

Joacim

Chtěl bych se s vámi poradit ohledně návrhu vhodné db struktury pro řízení přístupu pomocí ACL, koukal jsem na návod zde na nette, ale jedná se o starou verzi, u které chybí databázové schéma s rozložením a vazbami tabulek a nevím jestli je návod aktuální jelikož jsem se již mnohokrát setkal s tím že se třídy nacházejí jinde nebo se i jinak jmenují.

Návrh
(inspirováno z bakalářské práce UTB 2010 T.Marcaníka)

Pokud by byl někdo ochoten zveřejnit větší část svého řešení byl bych moc vděčný, abych nemusel zabíjet čas a vymýšlet to. Zatím používám Statickou verzi ACL pomocí Nette\Security\Permission

Chtěl bych, aby se po přihlášení daného uživatele generovalo Menu v mém CMS podle práv uživatele.
Při vytvoření uživatele mu hned přidělím i roly nebo role.

Možná je tento DB návrh dostačující, ale jelikož nejsem ještě nette matador, rád si nechám poradit.

Editoval Joacim (13. 5. 2015 12:09)

akadlec

Taky jsem to řešil, taky jsem měl složite DB struktury a nakonec jsem to zjednodušil a udělal si na to extension. Mám definované role a mám definované permissions a extensions se mě stará o kontrolu zda uživatel z dané role má povolen přístup.

Joacim

Já chci mít role, které nejsou pevně v kodu a jsou dobře editovatelné/nastavitelné pomocí UI a databáze, jelikož to nemám aplikaci jednoúčelovou, ale univerzální do které mám již připravené moduly atd:., kdyby na nette měli i ukázku DB tak bych to měl už napsané.

@akadlec – tohle řešení je taky pěkný, ale hledám ještě něco jednoduššího i když se asi nechám volně inspirovat, díky moc

Pokud má někdo i jiné řešení nebo někde vypátráte nette ACL DB strukturu, rád se inspiruji.

Editoval Joacim (13. 5. 2015 16:45)

enumag

Také raději používám řešení s rolemi definovanými v kódu. Hlavní důvod je ten že v Permission často používám assertační callbacky na ověření vlastnictví apod. – podobná oprávnění by se v db řešily poměrně špatně.

Joacim

To mě docela překvapujete, uvědomuji si složitost dyn. ACL ale i tak, pokud mám aplikaci kterou má 30 klientů tak nebudu každýmu do kodu psát práva s tím že si to za pul roku zase rozmyslí

enumag

Dle mých zkušeností se oprávnění moc často nemění. Pushnout klientovi jednou za půl roku commit s pár řádky je mnohem méně práce než to co navrhuješ. :-)

Joacim

Jasný, no já se informuji jak to vidíte, a podle toho se případně zařídím, dyn. ACL je zajímavé, ale zabere to dost času, ale když vím že do CMS bude přistupovat v jeden den více než 60 lidí a budou se mazat, přidávat dost často, začal jsem zvažovat i tuto možnost. Otázka je ovšem přínosnost/časová náročnost a chyby.

David Kudera

jinak kdyby jsi přeci jen nakonec šel cestou „přes kód“, tak jsem vytvořil tady jednu vychytávku. Je to pro snadnější tvorbu oprávnění hlavně ve spojení s ověřovacími callbacky, jak zmiňuje @enumag

Tomáš Votruba

Přehlednější architekturu a větší flexbilitu vidím ve Voters. Přidání nového pravidla pak spočívá pouze v přídání nové třídy.

akadlec

@Joacim ale ta ext odemně ti nikde nedefinuje jak máš role/pravidla definovat. Já osobně je mám třeba půl na půl, něco pomocí konfigurace a něco co se dynamicky určuje přes GUI a konkrétně toto řešení mám zahrnuto v CMS

akadlec

@TomášVotruba no to nevím, když těch pravidel budeš mít 10ky tak ti to poroste do hodně tříd. Já si třeba v konfigu přidám nové pravidlo a přes GUI už pak jen která role jak s daným pravidlem pracuje. Jediné co tam neřeším je jak bylo zmíněno vlastnictví, ale to proto, protože tohle zase řeším v datovém manageru kde potřebuju.