[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