[Zope-PTK] Announcing ZPatterns 0.4.3b1 and LoginManager 0.8.8b1

[Phillip J. Eby]

At 02:57 PM 10/19/00 +0000, Ty Sarna wrote:
>In article <39EED5F0.1D9C5628@maxnm.com>,
>Itamar Shtull-Trauring  <itamar@maxnm.com> wrote:
>> Michael Bernstein wrote:
>> 
>> > So which is it? Is the local roles fix in, or not?
>> > 
>> > I'd also be very interested in hearingzopee about this
>> > broken interface in Zope.
>> 
>> The broken interface is that Zope requires a list of all users, which may
>> not be available.  Instead, you should be able to type in a user's name,
>> Zope checks if it exists, and if it does lets you set its local roles.
>
>That's also a broken (user) interface, but not the one fixed by the
>"Local roles improvement patch" which is included in 0.8.8b1.  That one
>is a code interface issue: in order to find out what local roles a user
>has over an object, it asks for a list of all local roles for *all*
>users, and then pulls out the information for the one particular user. 
>The patch fixes that, making local roles computation much more
>efficient. 
>

A bit more background on this...  the code in question is needed to support
local role computation.  I've previously submitted this as a Collector
patch *and* as a dev.zope.org proposal.  Meanwhile, however, Ty and I
needed this for a project we were working on, so we went ahead and put it
in LoginManager.  The patch is 100% backward-compatible, unless you have
objects you've already custom-written a new local roles implementation.
But it enables the definition of more sophisticated local roles computation
by giving an accessed object the ability to inspect the user object
directly, rather than just giving it a user ID or name.

The other thing it does is make the security system run more efficiently by
using "short-circuit evaluation" that returns true as soon as a matching
role is found.  Ironically, all of Zope's roles implementation has access
to the list of roles that are wanted, yet this information is ignored and a
complete picture of a user's roles is always built, even if it means
traipsing up the entire acquisition hierarchy of an object and looking at
local roles on each parent.  The patch shortcuts this whenever it is known
that the caller doesn't really need a full list of roles (i.e., when all
that's going to end up being returned is a true or false value).  In that
case, it stops as soon as a role that would grant permission is found.

For information on both of these, see:

http://dev.zope.org/Wikis/DevSite/Proposals/UserProgrammableSecurityObjects

In essence, LoginManager 0.8.8b1 includes the code to implement everything
described in that proposal.