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],
...}
> * User.BasicUser.allowed() is the only method that
> "has a short-circuited version of getRolesInContext in it"
This is correct. But if you implement dynamic local roles per above,
you don't need to do this. You were right in an earlier post when you
said that when people said validate() they meant allowed(). (This is
what happens when you don't have well-defined naming standards!)
> 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.
> 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.
a.
--
Adrian van den Dries [EMAIL PROTECTED]
Development team www.dev.flow.com.au
FLOW Communications Pty. Ltd. www.flow.com.au
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
