Hash: SHA1

On 16/01/2004, at 9:23 AM, Jim Fulton wrote:

Dieter Maurer wrote:
Jim Fulton wrote at 2004-1-15 10:03 -0500:
Right. The name attribute was intended for attribute-based access.

IMO, it makes no sense to consider key values when doing security

I had thought we had more, but most of that logic is now in a ComputedAttribute __ac_local_roles__ and in our __getitem__ hooks. What we currently have is a BTree storing key -> value. Valid keys are defined by a schema. If that schema changes, we do not want to lose the information until we are sure it has been archived, but we no longer want it available.

The sorts of things we *were* doing was allowing access to
certain attributes if the currently authenticated user had
required permissions on a related object.

        eg. A bag-of-metadata has an associated Publisher object,
                and the Publisher has Editors (implemented as a local
                role assigned in the Publisher). Access to bits of
                metadata would be calculated based on the bag's schema,
                which determined if each bit was private, public or shared.
                Shared was available to people with certain permissions
                on the bag, or to people with certain permissions on the
                associated Publisher (the Editors). Some metadata has
                calculated privacy settings (eg. EmailAddress is shared
                or public depending on the value of PrivateEmailAddress)

We now have the situation that this is possible if bag-of-metadata
is accessed via getattr (stored as attributes on the object),
but not via getitem (stored anywhere else).

I can also imagine BTrees keyed to userid (eg storing settings),
where people can only access their branch or branches of people
in their workgroup.

BTW, telling me that an algorithm has changed doesn't constitute
a use case. :) I know that algorithm has changed.  I assert that
we don't need the feature that the change broke.  I am open
to evidence to the contrary.

Its probably a feature we don't *need*, but some of us happen to be using it, and have been using this documented feature since Zope 2.5. I can probably work around it (although it means the next milestone release next week will be on b3 instead of b4), but I'd assumed that if one person who is using the beta triggered this issue, there will be plenty more who may be upset when they try porting their apps to 2.7.0 release.

- -- Stuart Bishop <[EMAIL PROTECTED]>
Version: GnuPG v1.2.3 (Darwin)


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

Reply via email to