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 <[EMAIL PROTECTED]> 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.


Zope-PAS mailing list

Reply via email to