[Zope-PAS] Re: local roles plugins

[Jens Vagelpohl]

On Apr 18, 2005, at 9:17, Kapil Thangavelu wrote:

>
> On Apr 11, 2005, at 1:51 PM, Zachery Bir wrote:
>
>> On 2005-02-07 17:44:21 -0500, Kapil Thangavelu 
>> <hazmat at objectrealms.net> said:
>>
>>> hi folks,
>>> i'd like to see a new plugin type for local roles plugins. the major
>>> driving reason is to enable a local roles blocking policy on 
>>> containers.
>>> i've got a version of it implemented and if its sounds good i'll 
>>> setup a
>>> pas branch with the code. the implementation patches propertied user 
>>> and
>>> setups a new plugin type based on the following interface.
>>
>> How would this not be satisfied by writing a special user factory, 
>> whose user class specifies a different behavior for 
>> getRolesInContext()? This doesn't strike me as an interface that 
>> needs to go into the workings of PAS itself.
>
>
> agreed. the implementation itself was briefly done as a monkey patch, 
> which the previous email was an artifact of, and then changed to a 
> custom user factory and user class, which delegates to an internal 
> local roles plugin type. unfortunately i haven't had time to push any 
> of the other changes back into pas cvs, the core modifications/monkies 
> currently are just adding add/del user api implementations.

Actually, you need more than just getRolesInContext on your custom 
user. "allowed" needs to be overridden as well because the version on 
PropertiedUser explicitly foregoes calling getRolesInContext.

But that didn't solve all problems for my setup: Sometimes it does not 
seem possible to deduce the "real" context in the overridden 
getRolesInContext/allowed methods.

Imagine a structure where you have a portal with sub-portals. The PAS 
instance is in the portal, and I want to manipulate roles for requests 
that are done at the subportal level, based on a property of the 
subportal. If the requested page (a PageTemplate for example) is using 
a tool that resides in the main portal and I grab the tool inside the 
template and call a method with a simple...

foo here/portal_footool/foomethod

then the "object" that is passed into "allowed" has no context 
information linking it to the subportal. Its own context is the main 
portal. This is a complete blocker for that approach for me right now. 
At this point I'm not sure if there's a way to make this scheme work at 
all for my requirements.

jens