[Grok-dev] Re: local roles and REST

Philipp von Weitershausen philipp at weitershausen.de
Fri May 16 02:46:51 EDT 2008


whit morriss wrote:
> I was attempting to do some basic securing of REST methods ala::
> ...
>     @grok.require('almanac.add')
>     def POST(self):
> ...
> 
> almanac.add is a generic permission that gets granted to the 
> almanac.owner role on the container.  The local role of owner is granted 
> to the active principal at the time of the containers creation (using 
> subscribers).
> 
> My tests were blowing up until I (pdbed through the checker) and added 
> an adapter to zope.app.securitypolicy.interfaces.IPrincipalRoleMap from 
> my REST "view"::
> 
> @grok.adapter(AlmanacAPPBase)
> @grok.implementer(IPrincipalRoleMap)
> def context_role_manager(controller):
>     "Delegate to context"
>     return IPrincipalRoleMap(controller.context)
> 
> ...
> 
> Am I missing something elsewhere or are local roles not being applied by 
> default to REST views (grok 0.11.1)?

They never are. The way zope.app.securitypolicy works is acquisition 
(yes, there is a bit of acquisition in Zope 3 :). What I mean by that is 
it'll try to adapt the current object (in this case your view) to 
IPrincipalRoleMap, but if that doesn't work, it'll walk up the 
__parent__ ancestry until it finds the information.

Looking at how grok.REST is implemented (see components.py), it exactly 
fails to set __parent__ in its __init__. What it should do is:

   self.context = self.__parent__ = context

Note that browser views are ILocations which means they explicitly say 
"I'm part of the object hierarchy and I have __parent__ and __name__." 
Being views, REST objects probably should do the same. In fact, I don't 
see a good reason why they don't.



More information about the Grok-dev mailing list