ACL a formuláře/signály s vazbou na view?

Po diskusi s redem jsme došli k addProtection, předpokládám že token je vázán na specifický formulář a nemůže být použitý jiný token z jiné části aplikace? Dá se zkrátit expirace tokenu (session je overkill)?

Editoval Harrier (15. 12. 2016 18:05)

@Harrier addProtection je ochrana proti CSRF a ne autorizace.
Co se týče autorizace komponent tak vždycky můžeš vyplnit po svém metodu checkRequirements. Já si vystačím s kontrolou oprávnění na celou stránku případně v šabloně kontroluju jestli má právo dělat nějakou akci – potom zobrazím editační formulář.

btw. před provedením signálu se volá startup a checkRequirements, kde můžeš ten signál odeslání formuláře znehodnotit vyhozením třeba erroru 403.

@Harrier „právě po zkušenostech s ACL“ … jak to myslis?

imho: „nechci přidělávat pravidla pro signály a ani kontrolovat isAllowed na každém kroku“ to je to co programator dela, aby ACL fungovalo. Pak uz je jen na jeho sikovnosti (copy/paste vs nejaka hierarchie) aby to nebyl takovej pain.

Ja mam treba ACL nastavene v configu

authorizator:
    class: Nette\Security\Permission
    setup:
        - addRole('guest')
        - addRole('user')
        - addRole('writer', 'user')
        - addRole('moderator', 'writer')
        - addRole('admin', 'writer')
        - addRole('root', 'admin')

        - addResource('User')
        - allow('admin', 'User', 'view')
        - allow('admin', 'User', 'add')
        - allow('admin', 'User', 'edit')

        - addResource('UserSettings')
        - allow('user', 'UserSettings', 'view')
        - allow('user', 'UserSettings', 'add')
        - allow('user', 'UserSettings', 'edit')

        - addResource('Form Example')
        - allow('user', 'Form Example', 'navigation')
        - allow('user', 'Form Example', 'view')
        - allow('user', 'Form Example', 'edit')

        - addResource('List Example')
        - allow('user', 'List Example', 'navigation')
        - allow('user', 'List Example', 'view')
        - allow('user', 'List Example', 'edit')

        - addResource('Simple Example')
        - allow('user', 'Simple Example', 'navigation')
        - allow('user', 'Simple Example', 'view')
        - allow('user', 'Simple Example', 'edit')
        - allow('user', 'Simple Example', 'add')
        - allow('user', 'Simple Example', 'remove')

        - addResource('Component')
        - allow('user', 'Component', 'navigation')
        - allow('user', 'Component', 'view')

        - addResource('Document')
        - allow('user', 'Document', 'navigation')
        - allow('user', 'Document', 'view')
        - allow('user', 'Document', 'edit')
        - allow('root', 'Document', 'add')
        - allow('root', 'Document', 'remove')

a pri kazde nutne prilezistosi se zeptam zdali uzivatel tu danou vec muze udelat. Ma to sve mouchy (cache identity), ale pro me potreby je to dostatecne

F.Vesely napsal(a):

Pokud ti jde o to, ze formular je zpracovan ve vsech views, tak muzes klidne dat kontrolu na prava do funkce createComponent.

Tohle bude asi nejlepší řešení, dík.

Ale na tohle zas bacha. Můžeš se pak rozhodnout, že ten formulář použiješ někde jinde trochu jinak a budeš ho mít bez kontroly. Osobně jsem za to, že kontrola by měla být všude, kde je to možné – v samotné komponentě, action/render metodě (pokud tam máš jen ten konkrétní formulář) i v createComponent a, pokud používáš nějaké ORM, tak třeba i v entitě. Je to sice opruz, ale bezpečnost musí být na prvním místě.

To sice ano, ale všeho s rozumem. Pak se rozhodneš pro nějakou změnu a její implementace bude k po..... ;) Je proto vhodněji analyzovat co se děje a ověření dát tam kde to má smysl. Takové ověření práv v entitě je imho nesmysl, to bys měl dělat tam kde tu entitu vytváříš/ukládáš.