On Thu, Mar 06, 2003 at 09:19:37AM +1100, Adrian van den Dries wrote:
> On March  5, Paul Winkler wrote:
> > I've been trying to understand how to implement dynamic local roles,
> Customise the Folder class and override __ac_local_roles__ with a
> method that returns a dictionary mapping users to roles for that object:
>   {user: [local,roles],
>    ...}

well, that's appealingly simple :)

but I have doubts:

* more coupling - since i'm going to have to get the users 
from the external source too (LDAP in this case), i then
have 2 classes (the UserFolder and the Folder) that have
to know about the external source. 

* performance hit - along with the previous concern, i now always have to
do 2 queries of the external source: one for the userfolder to get 
the user, one for this Folder to look up the roles. I don't know if
I care about this one...

* one more detail to pay attention to during normal zope admin work -
This is a real problem, as we're going to have a large amount  of
stuff protected this way and it's going to grow all the time.
AFAICT I'd have to use this customized Folder instead of 
normal Folders for every place where i want to keep content
that I store this way, because *everything* under the special Folder
acquires the same local role.  Why? Because at the time that 
the Folder gets asked for its local roles, it doesn't know what the 
leaf object was.  
This also means that I can't use other Folderish things e.g. LocalFS
and generate varying local roles for its contained items.

OTOH, doing the magic in user.allowed() would mean 
I'd only need one "special" UserFolder instance at the top of the
hierarchy, and then everything else Just Works regardless of
what folderish thing it is and all my LDAP-related code would
be in this UserFolder class.

am i overlooking something?

> >     *  User.BasicUser.allowed() is the only method that
> >        "has a short-circuited version of getRolesInContext in it"
> This is correct.


> >         which calls ZopeSecurityPolicy.validate()
> This does the work of validating access to object *after* the object
> has been allowed().  ie, to figure out permissions on callables to
> avoid a trojan attack.  This is not the validate() you are looking
> for.

"You don't need to see his identification... he can
go about his business... move along" :)

> >      One more thing: AFAICT, ZopeSecurityPolicy.checkPermission()
> >      and User.has_permission() are purely for informational purposes -
> >      e.g. you can call them in your app to find out something,
> >      but they are not used by the internals to grant or deny access.
> >      True?
> True.



Paul Winkler

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to