[Flow] The confusing policy role stuff

[Jan Greth]

Hey Steffen,

thanks for your detailed advice. I think the "mindworm" is gone now... 
:) Everything clear now.

Greetings,
Jan


Am 12.02.2014 00:27, schrieb Steffen Wickham:
> Hello Jan,
>
> please see my answers below your specific question :)
>
>
>
> Am 11.02.2014 22:48, schrieb Jan Greth:
>> Hey Aimo,
>>
>> thanks for your reply. I'll give it a try.
>>
>>> First of all: make everything that should be protected a resource.
>>> E.g.
>>>
>>> resources:
>>>     methods:
>>>       'Foo':
>>> 'method(Vendor\Package\Controller\CoffeeBeanController->(index|show)Action())'
>>>       'Bar':
>>> 'method(Vendor\Package\Controller\CoffeeBeanController->(new|create|edit|update|delete)Action())'
>>>
>>
>> Ok, just to clarify my confused mind: an action / controller / etc NOT
>> mentioned under "resources: methods:" is NOT protected and allways
>> callable. Is that right?
> That's correct. You have to tell Flow which resources have to be
> protected through a declaration like the one above. Does a Controller or
> method not match any defined resource, it is meant as public access and
> access will be grant to Everybody.
>
>
>> Wire users and resources via the ACLs
>>>
>>> acls:
>>>     ' DefaultUser ':
>>>       methods:
>>>         'Foo':       GRANT
>>>     ' AdvancedUser ':
>>>       methods:
>>>         'Bar':    GRANT
>>
>> Are the singlequotes (" ' ") around DefaultUser, AdvancedUser, Foo and
>> Bar needed? couldn't find a hint in the Docs...
> Nope, please remove the quotes, they are not necessary.
>
>
>>
>> And as allways when diggin' into new things during the last minutes
>> ther appeared some further questions:
>>
>> 1. Are there / which options in Settings.yaml have effects on the
>> Settings made in Policy.yaml?
> Please have a look in the main Settings.yaml delivered with TYPO3.Flow
> below "TYPO3: Flow: security" would affect the whole security party of
> Flow. The only options which will affect Policy.yaml directly is
> "enable" (line 226) and "allowAccessIfAllVotersAbstain" (line 309) IMHO.
> With security you could disable all security features, with the
> "allowAccessIfAllVotersAbstain" you can allow access to secured methods,
> when one or more voter abstain to vote for a potential insecure call.
>
>
>>
>> 2. Can a Action be mentioned more than one time in resources:methods: ?
>> E.g.:
>> One: 'method(Vendor\Package\Controller\.*Controller->index.*())'
>> Two: 'method(Vendor\Package\Controller\AbcController->.*Action())'
>> What happens to AbcController->indexAction() if i 'GRANT' One and
>> 'DENY' Two?
> Yes, you can add multiple resource definitions which covers the same
> method, but it can get complicated. I hadn't tried it by myself till now.
> The answer to your second question is pretty simple: Access will be
> denied (even when there were more GRANT items then DENY).
>
> A quote from
> http://docs.typo3.org/flow/TYPO3FlowDocumentation/TheDefinitiveGuide/PartIII/Security.html#policies-aka-access-control-lists-acls:
> "If a DENY privilege is configured for one of the user's roles, access
> will be denied
> no matter how many grant privileges there are in other roles."
>
> When you want to prevent executing 'two' for normal users, just do not
> add a GRANT statement for their the role (=> access will be denied). For
> a special role you add the GRANT statement and it can be accessed.
> So be careful using DENY, it is IMHO only useful for resource
> definitions which checks parameters as well. A perfect resource will be
> the Policy.yaml from TYPO3.Neos Package:
> https://git.typo3.org/Packages/TYPO3.Neos.git/blob/HEAD:/Configuration/Policy.yaml
>
>
>> 3. Assuming i have the roles User: [] and Superuser: ['User']
>> User should be denied to access a method, Superuser should be able to
>> call. How would i write that?
> resources:
>    methods:
>      Vendor_Package_SpecialOfferController:
> 'method(Vendor\Package\Controller\SpecialOfferController->.*Action())'
>
> roles:
>    User: []
>    Superuser: [User]
>
> acls:
>    Superuser:
>      methods:
>        Vendor_Package_SpecialOfferController: GRANT
>
>
>>
>> 4. Is it necessary/good/not good to Configure Firewall AND ACLs? Under
>> which circumstances would you do what?
> I think there is no "good" or "bad" in general. You can add firewall
> rules beside your ACLs, that's fine. But keep in mind: Every new rule
> will make it more complicated to maintain and debug access rules.
>
>>
>> I hope you can help me with this again. Nice evening and greetings
>> from Bavaria,
>> Jan
>
> Have a nice morning and many greetings from Lower-Saxony,
> Steffen :)
>