[Grok-dev] Security declarations

Jan-Wijbrand Kolman janwijbrand at gmail.com
Tue Oct 13 03:58:26 EDT 2009

Martijn Faassen wrote:
> Hey,
> Marc Rijken wrote:
>> Thanx for your prompt reply. I have tried is in grok0.14. I did not get 
>> any errors, but it did not work. When I changed the classes in to 
>> strings it did work. I have moved the code to grok1.0 and it works as 
>> expected. I'm not sure that was the only difference.
>> BTW this behaviour is not document on 
>> http://grok.zope.org/doc/current/reference/directives.html#security-directives 
>> which states  " permission – the name of the permission that is required"
> Thanks, that's indeed a documentation bug.
> I've updated the documentation to reflect this now in SVN. One question 
> is whether this really works with Role. I couldn't find a test that 
> tests this, so that's a testing issue at least. I tried adjusting a test 
> to try it out, but I got errors in my test run.
> This implies that the documentation in SVN is now ahead of the code. 
> Could someone add a test that tests direct permission references in 
> grok.Role?
> This ought to work:
> class MyPermission(grok.Permission):
>      ...
> class MyPermissions2(grok.Permission):
>      ...
> class Foo(grok.Role):
>      ...
>      grok.permissions(MyPermission, MyPermission2)
> Thanks, brave test-adder. :)

I do not think this actually works with Role components currently.

The "trick" that knows how to handle either the Permission component 
class itself or the name of this component, is implemented in the 
grokcore.security.require() directive.

I agree it should work as symetrical as possible.

Be aware though of the fact that Zope itself still identifies 
permissions primarily through their name. So, this could eventually trip 
you up in case you're using APIs that work with permissions - such as 
permission mappings for example.

As a result we at THA still primarily use the names after all, 
identified trough constants in a central permission.py module.

Alas, let's see if we can get the behaviour symetric in the Role components.


More information about the Grok-dev mailing list